Hallo Leute, vielleicht kennt jemand von Euch eine Lösung für mein aktuelles Problem. Ich möchte Daten auf eine SD-Karte schreiben. Das Format ist vorgegeben und besteht im Wesentlichen aus mehreren verketteten Listen die unterschiedlich schnell wachsen können. Dabei tritt nun das Problem auf, dass die Schreiblatenz der SD-Karte so groß wird, dass mein FIFO im Ram überläuft bzw. Datensätze verworfen werden müssen. Im Wesentlichen suche ich ein Ram o.Ä. das mit möglichst ((TM), ich weiß, ich weiß) wenig Platz (Bauteil und Verdrahtung auf der Platine) auskommt. 2 MiB wären wahrscheinlich meine Minimalanforderung, gerne aber auch mehr. Was ich mir bisher überlegt habe: - Idealerweise würde ich ein serielles SRAM im SOT32 o.Ä. per SPI anbinden, aber derartiges habe ich nur bis 1 MBit gefunden - Controller mit viel internem Ram: Sind in dieser Größenordnung nich alltäglich und haben meist selbst ein großes Gehäuse oder unsäglich kleine BGA-Gehäuse - Externer SRAM: ca 6x8 mm als BGA, relativ viele Leitungen, teuer - Externer SDRAM: auch ca 6x8 mm als BGA, relativ viele Leitungen, gemessen an Kapazität günstiger, aber nicht in kleinen Größen zu bekommen - FRAM, MRAM: nicht in meiner Größe verfügbar (?) oder sehr großes Package - Dataflash: Anzahl Schreibzyklen begrenzt, Latenz relativ groß. Mir ist klar, dass ich einen Tod sterben muss. Ich möchte halt den besten wählen und sicher sein, dass ich nichts vergessen oder übersehen habe. Weiß jemand Rat? Viele Grüße Karl
@Karl (Gast) >Im Wesentlichen suche ich ein Ram o.Ä. das mit möglichst ((TM), ich >weiß, ich weiß) wenig Platz (Bauteil und Verdrahtung auf der Platine) >auskommt. 2 MiB wären wahrscheinlich meine Minimalanforderung, gerne >aber auch mehr. Wie klein ist klein für dich? 1cm^2? Was für einen Prozessor hast du? >- Idealerweise würde ich ein serielles SRAM im SOT32 o.Ä. per SPI >anbinden, aber derartiges habe ich nur bis 1 MBit gefunden Ist um Faktor 16 zu klein ;-) >- Controller mit viel internem Ram: Sind in dieser Größenordnung nich >alltäglich und haben meist selbst ein großes Gehäuse oder unsäglich >kleine BGA-Gehäuse Gibt es nicht wirklich. >- Externer SRAM: ca 6x8 mm als BGA, relativ viele Leitungen, teuer >- Externer SDRAM: auch ca 6x8 mm als BGA, relativ viele Leitungen, >gemessen an Kapazität günstiger, aber nicht in kleinen Größen zu >bekommen Besser wird es kaum!! Beitrag "Re: Viel RAM am kleinen Controller" >- FRAM, MRAM: nicht in meiner Größe verfügbar (?) oder sehr großes >Package >- Dataflash: Anzahl Schreibzyklen begrenzt, Latenz relativ groß. Nicht sinnvoll. >Mir ist klar, dass ich einen Tod sterben muss. Kannst du denn nicht deine SD-Karte langsamer beschreiben? Woher kommen die Daten? Kann man die Datenquelle ausbremsen (Handshake?)
Hi Karl, schon mal bei Mouser gesucht? Kurze suche nach 'SPI Ram' ergibt z.B.: 727-FM25V20A-G (SOIC-8,2Mbit) 727-CY15B104Q-LHXI(TDFN-8, 4Mbit) Beide sind vom Verdrahtungsaufwand trivial(8 pins), das DFN8 Gehäuse ist mit 5x6mm zudem noch etwas kleiner als die von dir genannten. Was den Speicherplatz angeht, ich hab einfach die obersten der Liste genommen, es gibt zB noch: 797-25FL032P0XNFI011 (USON-8, auch 5x6mm, 32Mbit). Mir faellt gerade auf, dass ich die Mouser Nummern kopiert habe anstatt die Produktbezeichnungen. Nik
Nik B. schrieb: > 797-25FL032P0XNFI011 (USON-8, auch 5x6mm, 32Mbit). Das ist kein RAM, das ist ein Flash-ROM.
Ersetze deine SD Karte durch 4xMicro-SD und mach was Raid0 artiges.
Falk B. schrieb: > Wie klein ist klein für dich? 1cm^2? Was für einen Prozessor hast du? Kleiner wäre besser, mit restlichem Platz für Verdrahtung aber ok. Nutze aktuell den STM32F405 mit 64 Pins. Der ist auch recht voll belegt. Für S(D) Ram müsste ich auf BGA gehen. Im Prinzip nicht so schlimm aber die 0.4 mm Pitch schrecken mich schon ab muss ich sagen, auch was das Layout und die Kosten für die Platine angeht. > Ist um Faktor 16 zu klein ;-) Ja :( > Besser wird es kaum!! Habe ich befürchtet. > Beitrag "Re: Viel RAM am kleinen Controller" Danke. > Kannst du denn nicht deine SD-Karte langsamer beschreiben? Woher kommen > die Daten? Kann man die Datenquelle ausbremsen (Handshake?) Daten kommen von mehreren CAN und können nicht gedrosselt werden. Die Daten werden teilweise interpretiert und auf aktuell microSD, später eMMC gespeichert. Eine Nachricht am CAN bläht sich mit Zeitstempel etc auf ca 30 Bytes auf. In welche der Listen eine Nachricht bzw. deren interpretierte Daten muss, entscheidet sich erst zur Laufzeit und soll absichtlich "online" erledigt werden. Nik B. schrieb: > schon mal bei Mouser gesucht? Ja, auch Farnell. Leider nichts in der Größenordnung wie ich es bräuchte bzw. mir vorgestellt habe. Lukas S. schrieb: > Ersetze deine SD Karte durch 4xMicro-SD und mach was Raid0 artiges. Es ist schon eine µSD. Inwiefern hilft mir Raid 0 beim garantierten überbrücken der Schreib_latenz_? Abgesehen davon habe ich nur einen SDHC und der mittlere Durchsatz ist kein Problem. Falls ich Dich hier falsch verstanden habe oder was übersehe, bitte erklär's mir noch mal.
RAM braucht halt relativ viel Chipfläche. Also SOT32 wird da z.B. definitiv nicht gehen ;-) Ein STM32F7 im 13x13mm BGA hätte ja immerhin schonmal ca. 512 KByte RAM intern - evtl. kannst Du die Daten/Listen ja irgendwie effizienter Speichern / komprimieren (mit der Rechenleistung des F7... sofern es keine zufälligen Daten sind)
Karl schrieb: > Dabei tritt nun das Problem auf, > dass die Schreiblatenz der SD-Karte so groß wird, dass mein FIFO im Ram > überläuft bzw. Datensätze verworfen werden müssen. Eventuell kann man auch hieran noch was optimieren... Was für eine Datenrate hast du denn?
Karl schrieb: > Lukas S. schrieb: >> Ersetze deine SD Karte durch 4xMicro-SD und mach was Raid0 artiges. > Es ist schon eine µSD. Inwiefern hilft mir Raid 0 beim garantierten > überbrücken der Schreib_latenz_? Abgesehen davon habe ich nur einen SDHC > und der mittlere Durchsatz ist kein Problem. Falls ich Dich hier falsch > verstanden habe oder was übersehe, bitte erklär's mir noch mal. Abwechselnd auf Karte 1 und 2 (und 3 und 4) Speichern, nicht gleichzeitig? Dann wäre doppelt (viermal) so oft eine zum Schreiben bereit (Speichern in festen Intervallen vorbereiten).
Mac G. schrieb: > Dann wäre doppelt (viermal) so oft eine zum Schreiben bereit (Speichern > in festen Intervallen vorbereiten). Das ist leider nicht garantiert.
Mac G. schrieb: > RAM braucht halt relativ viel Chipfläche. Also SOT32 wird da z.B. > definitiv nicht gehen ;-) Ich meinte ja auch SOT23 ;-) Wobei man sich im allgemeinen schon die Frage stellen muss, ob man auf dem Holzweg ist, wenn es die erträumten Bauteile nicht gibt. Man ist ja selten der erste und einzige, der ein bestimmtes Problem behandelt. > Ein STM32F7 im 13x13mm BGA hätte ja immerhin schonmal ca. 512 KByte RAM > intern - evtl. kannst Du die Daten/Listen ja irgendwie effizienter > Speichern / komprimieren (mit der Rechenleistung des F7... sofern es > keine zufälligen Daten sind) Hab ich auch schon überlegt. Die H7 gäbe es sogar mit 1 MiB (irgendwann). Kompression: Verstehe ich nicht viel davon, es ist abgesehen vom Zeitstempel aber vom worst case auszugehen. Ich lasse mich aber auch gerne eines besseren belehren. Hast Du was konkretes im Sinn? Dr. Sommer schrieb: > Eventuell kann man auch hieran noch was optimieren... Was für eine > Datenrate hast du denn? Optimieren kann man sicher was. Wenn es den Speicher aus meinen Träumen gäbe (TM), könnt ich mir das halt sparen. ;-) Aktuell knapp 0.7 MiB/s die sich relativ beliebig auf die einzelnen verketteten Listen aufteilen können. Ich kann nicht vorhersehen in welche Liste was kommt, so dass im schlimmsten Fall alles in einen einzigen FIFO muss. Da könnte man schon ansetzen wenn ich so drüber nachdenke. Aktuell sieht es so aus: - Jeder CAN Kanal hat einen relativ kleinen FIFO, in den die empfangenen Nachrichten rein kommen (aus der RX ISR) - Es gibt für jeden CAN Kanal einen Thread der den CAN-FIFO leert, die Daten interpretiert und die Daten erzeugt, die anschließend auf die Karte sollen. An dieser Stelle wird auch entschieden, in welche Liste innerhalb der Datei die Daten kommen. - Für jede Ziel-Liste in der Datei gibt es einen FIFO. Diese werden gepollt und wenn genug Daten zum Schreiben auf die Karte vorhanden sind, wird ein Block weggeschrieben (aktuell 4 kiB, man muss ja auch den Durchsatz schaffen) Diese FIFOs laufen aktuell über. Eine mögliche Lösung wäre eben, diese FIFOs groß genug zu machen. Das würde nicht so viel über den Haufen schmeißen in der SW. Bei genauerer Betrachtung lohnt es sich aber wahrscheinlich die CAN FIFOs größer zu machen und die Auswerte-Threads so lange zu blockieren bis in den Listen FIFOs wieder Platz ist, dann erspare ich mir für jeden Listen FIFO den Worst-Case vorzuhalten.
Karl schrieb: > Aktuell knapp 0.7 MiB/s Ach das ist ja harmlos! Bei einer schlauen™ Implementierung der Schreibroutine und einer guten SD-Karte (z.B. Samsung Evo) schafft man das mit 64 KB SRAM, also zB einem STM32F407.
Um welche Stückzahlen geht es denn? 1? 10? 100? 1000? Eventuell passt ja so etwas: http://www.ingenic.com/en/?newton/id/12.html Da sind in den Prozessor selber schon 32 MByte LPDDR mit hineingepackt worden. fchk
Dr. Sommer schrieb: > Ach das ist ja harmlos! Bei einer schlauen™ Implementierung der > Schreibroutine und einer guten SD-Karte (z.B. Samsung Evo) schafft man > das mit 64 KB SRAM, also zB einem STM32F407. Das ist nicht sehr hilfreich. Ich weiß jetzt natürlich, dass meine Implementierung nicht schlau ist aber sonst auch nichts. :-P 0.7 MiB/s * 100 ms rechnen und abrunden kann ich selbst. Was Du dabei so trivial übersiehst ist, dass die Schreiblatenz nicht garantiert ist (zumindest habe ich garantierte Schreiblatenz nur bei einigen wenigen eMMC, z.B. von Greenliant nach NDA gefunden). Weiterhin gibt es auch noch andere, z.B. dateisystembedingte Latenzen. Es soll ja nicht "raw" auf das Kärtchen. Und jezt, großer Meister, zeig her was Du kannst :-) SCNR
Das bei der recht geringen Datenrate so viel RAM gebraucht wird, glaube ich auch nicht. Allerdings gibt es 4 MBit (FRAM) in SO8 CY15B104Q bei Digikey und Mouser.
Karl schrieb: > Was Du dabei so > trivial übersiehst ist, dass die Schreiblatenz nicht garantiert ist > (zumindest habe ich garantierte Schreiblatenz nur bei einigen wenigen > eMMC, z.B. von Greenliant nach NDA gefunden). Richtig. Deswegen nimmt man ja eine Karte bei der es erfahrungsgemäß™ passt, wie eben Samsung Evo. Karl schrieb: > Weiterhin gibt es auch > noch andere, z.B. dateisystembedingte Latenzen. Es soll ja nicht "raw" > auf das Kärtchen. Korrekt. Ist möglich. Karl schrieb: > Und jezt, großer Meister, zeig her was Du kannst :-) Ich habe eine Implementierung geschrieben die 1 MByte/sec kontinuierlich auf eine Samsung Evo SDHC-Karte mit 64 KB RAM schreibt, natürlich in Dateien des FAT32-Systems, bei <1% CPU-Last. Bei Interesse könnte man über eine Lizensierung reden.
Uwe B. schrieb: > Allerdings gibt es 4 MBit (FRAM) in SO8 CY15B104Q bei > Digikey und Mouser. Es war schon immer etwas teurer, einen besonderen Geschmack zu haben. Knapp 80€ für 2MB. ;-)
Frank K. schrieb: > Um welche Stückzahlen geht es denn? 1? 10? 100? 1000? > > Eventuell passt ja so etwas: > http://www.ingenic.com/en/?newton/id/12.html > > Da sind in den Prozessor selber schon 32 MByte LPDDR mit hineingepackt > worden. Eher 100 als 1000. Das ist in der Tat interessant. Hast Du damit Erfahrungen?
@Karl (Gast) >Wobei man sich im allgemeinen schon die Frage stellen muss, ob man auf >dem Holzweg ist, wenn es die erträumten Bauteile nicht gibt. Man ist ja >selten der erste und einzige, der ein bestimmtes Problem behandelt. Eben. >Aktuell knapp 0.7 MiB/s Wozu brauchst du dann 2MB? Gescheite SD-Karten haben max. um die 300ms Gedenkpause beim Schreiben, also musst du für 300ms++ Daten zwischenpuffern. Wenn wir mal von 500ms ausgehen, sind das gerade mal 350kB. Das ist deutlich wenigern als 2MB. >- Für jede Ziel-Liste in der Datei gibt es einen FIFO. Diese werden >gepollt und wenn genug Daten zum Schreiben auf die Karte vorhanden sind, >wird ein Block weggeschrieben (aktuell 4 kiB, man muss ja auch den >Durchsatz schaffen) Diese FIFOs laufen aktuell über. Wie groß sind sie denn? Und vor allem, wie ist der Gesamtaufbau der Software? Ich hoffe mal, daß die CAN-Nachrichten per Interrupt gelesen und verarbeitet werden und dann im FIFO landen. Threads sind dem zwar sehr ähnlich, aber da wäre ich vorsichtig, Prioritäten und so. >Bei genauerer Betrachtung lohnt es sich aber wahrscheinlich die CAN >FIFOs größer zu machen und die Auswerte-Threads so lange zu blockieren >bis in den Listen FIFOs wieder Platz ist, dann erspare ich mir für jeden >Listen FIFO den Worst-Case vorzuhalten. Uhhhhh!!! Das Wort Blockieren ist gar nicht gut!!!! Ich hab mal vor Jahren einen DMX-Rekoder mit einem kleinen AVR gebaut, der mußte 22kB/s von SD-Karte lesen bzw. schreiben und nebenher auch noch DMX lesen bzw. generieren. Das lief erstaunlich flott, mittlere CPU-Last nur 30% bei 16 MHz Takt. Der Trick ist halt, eben NICHT irgendwas zu blockieren, sondern alle Tasks etc. müssen nur dann arbeiten, wenn es wirklich was zu tun gibt. Damit werden die FIFOs auch optimal ausgenutzt. Siehe Multitasking. Der SD-Kartenzugriff lief als normale Funktion in einer State machine in der Hauptschleife, die DMX-Geschichte als State Machine in mehreren ISRs. Da wurde nie irgendwas blockiert. Den externen SRAM von gut 56 kB konnte ich voll für meine FIFOs nutzen, was bei SCHLECHTEN SD-Karten auch nötig war, die hatten teilweise bis zu knapp 1s!!! Gedenkpause, wenn man was geschrieben hat! Das alles war einfaches, kooperatives Multitasking ohne RTOS und Threads.
A. K. schrieb: >> Allerdings gibt es 4 MBit (FRAM) in SO8 CY15B104Q bei >> Digikey und Mouser. > > Es war schon immer etwas teurer, einen besonderen Geschmack zu haben. > Knapp 80€ für 2MB. ;-) FRAM ist jetzt nicht so wunderbar. Das hat eine begrenzte Lebensdauer. Jeder Lesezyklus (!) ist gleichzeitig ein Schreibzyklus. Aus meiner Sicht ist ein externes RAM eh keine gute Idee: Das erfordert einen weiteren Buffer (schreib / lese) einen DMA- Kanal, Management und wasweisichnochalles. Da wäre eher zu versuchen, das anders in den Griff zu bekommen: - Nächstgrößeren Controller nehmen, mit mehr RAM - Statt SPI SDIO verwenden - schnellere SD-Karte nehmen - Frequenz der SPI aufdrehen - Statt SD-Karte ein NOR-Flash nehmen Jetzt ist das NOR-Flash zwar nicht schneller, aber vorhersagbarer, was das Timing angeht...
Dr. Sommer schrieb: > Karl schrieb:> Richtig. Deswegen nimmt man ja eine Karte bei der es erfahrungsgemäß™ > passt, wie eben Samsung Evo. Geht nicht. Ich habe mit SD-Karten von SanDisk und Samsung sehr schlechte Erfahrungen gemacht was die Datensicherheit angeht, insbesondere wenn man einen Schreibvorgang durch Spannungsausfall abbricht. Der Witz dabei ist, dass es mit alten Karten ging und irgendwann nicht mehr. Neues Innenleben im alten µSD Gehäuse wahrscheinlich. Aktuell verwende ich Swissbit. > Ich habe eine Implementierung geschrieben die 1 MByte/sec kontinuierlich > auf eine Samsung Evo SDHC-Karte mit 64 KB RAM schreibt, natürlich in > Dateien des FAT32-Systems, bei <1% CPU-Last. Bei Interesse könnte man > über eine Lizensierung reden. Mit kontinuierlich schreiben meinst Du streamen? Hast du das Dateisystem selbst implementiert? Garantierst Du das auch bei Beliebigem Zustand der FAT? Garantierst Du das auch bei beliebigem fseek() innerhalb einer fragmentierten 4 GiB Datei? Falls Du die letzten beiden Fragen mit "ja" beantworten kannst, hätte ich gerne eine Preisindikation und welches Lizenzmodell Dir vorschwebt.
Karl schrieb: > Dr. Sommer schrieb: >> Karl schrieb:> Richtig. Deswegen nimmt man ja eine Karte bei der es > erfahrungsgemäß™ >> passt, wie eben Samsung Evo. > Geht nicht. Ich habe mit SD-Karten von SanDisk und Samsung sehr > schlechte Erfahrungen gemacht was die Datensicherheit angeht, > insbesondere wenn man einen Schreibvorgang durch Spannungsausfall > abbricht. Ja, bei Spannungsausfall beim Schreiben ist keinerlei Datensicherheit garantiert. > Der Witz dabei ist, dass es mit alten Karten ging und > irgendwann nicht mehr. Neues Innenleben im alten µSD Gehäuse > wahrscheinlich. Aktuell verwende ich Swissbit. Ok, da müsste man gucken ob die passen. > >> Ich habe eine Implementierung geschrieben die 1 MByte/sec kontinuierlich >> auf eine Samsung Evo SDHC-Karte mit 64 KB RAM schreibt, natürlich in >> Dateien des FAT32-Systems, bei <1% CPU-Last. Bei Interesse könnte man >> über eine Lizensierung reden. > > Mit kontinuierlich schreiben meinst Du streamen? Ja, typische Logging-Anwendung eben. > Hast du das Dateisystem selbst implementiert? Ja. > Garantierst Du das auch bei Beliebigem Zustand der FAT? Nein, das ist quasi unmöglich. Um maximale Performance zu ermöglichen (laut SD-Spezifikation!) braucht man große zusammenhängende freie Blöcke. Meine Implementation benötigt immer einen komplett freien Sektor in der FAT, d.h. 128 Cluster = 4 MB (bei den üblichen 32KB Clustern). Allerdings fragmentiert meine Implementation das Dateisystem gar nicht - wenn man also mit einer leeren Karte startet ist die Performance optimal bis die Karte voll ist, auch wenn man zwischendurch abschaltet (es bleiben nur ggf. Lücken bis max 4 MB zwischen den Dateien). > Garantierst Du das auch bei beliebigem fseek() innerhalb einer > fragmentierten 4 GiB Datei? Nein, denn ich brauche zum Loggen kein fseek(). Es wird wie gesagt nur kontinuierlich ein Stream geschrieben, Sprünge sind nicht möglich. > Falls Du die letzten beiden Fragen mit "ja" beantworten kannst, hätte > ich gerne eine Preisindikation und welches Lizenzmodell Dir vorschwebt. Das sollten wir falls du noch Interesse hast lieber privat besprechen ;-) Du kannst ja mal eine Mail-Adresse nennen...
Karl schrieb: > Frank K. schrieb: >> Um welche Stückzahlen geht es denn? 1? 10? 100? 1000? >> >> Eventuell passt ja so etwas: >> http://www.ingenic.com/en/?newton/id/12.html >> >> Da sind in den Prozessor selber schon 32 MByte LPDDR mit hineingepackt >> worden. > > Eher 100 als 1000. > Das ist in der Tat interessant. Hast Du damit Erfahrungen? Speziell mit diesem Chip nicht, aber mit einem Vorgänger. Der hat 128MB drin, aber den gibts nur noch begrenzte Zeit zu kaufen. Diese Dinger sind für Tablets, Uhren und sowas gedacht. Mein Arbytegeber macht Boards mit diesen Prozessoren. fchk
Karl schrieb: > Das Format ist vorgegeben > und besteht im Wesentlichen aus mehreren verketteten Listen die > unterschiedlich schnell wachsen können. Es ist doch immer wieder die gleiche Leier: Da schreibt ein TO, daß irgendwelche Randbedingungen fest vorgegeben seien und folglich indiskutabel - und jetzt kommt er mit der Lösung seines Problemes nicht zu Potte und fragt deswegen hier an. So geht das nicht. Anstatt ein mechanisch winziges RAM zu suchen, solltest du lieber über deine Randbedingungen nachdenken. Schmeiß sie einfach über den Haufen und denke dir eine sinnvollere (weil realisierbare) Lösung deines eigentlichen Problems aus. Das ist weitaus sinnvoller, als mit Gewalt einer nicht tragfähigen Idee nachzurennen. W.S.
> .. verkettete Listen .. > .. 700 kB/s > Ich habe mit SD-Karten von SanDisk und Samsung sehr schlechte Erfahrungen gemacht was die Datensicherheit angeht, insbesondere wenn man einen Schreibvorgang durch Spannungsausfall abbricht. Sorry irgendwas ist voll daneben. Die Anforderungen und Annahmen sind Muell. Verkettete Listen ? Dann ist die Performance schon zu Beginn weg im Keller. Die Geschwindigkeit ist nichts ! Eine moderne SD Karte macht 90 MByte beim Schreiben. Ja, und die Spannung sollte man schon halten koennen. Was soll denn das ? Erzaehl mal woher diese sinnlosen Anforderungen kommen. An welchen Controller wurde denn gedacht. Der Poster hat etwas wenig Ahnung fuer ein solches Projekt. Wahrscheinlich ist man schon zeitlich im Verzug.
:
Bearbeitet durch User
Falk B. schrieb: >>Aktuell knapp 0.7 MiB/s > > Wozu brauchst du dann 2MB? Gescheite SD-Karten haben max. um die 300ms > Gedenkpause beim Schreiben, also musst du für 300ms++ Daten > zwischenpuffern. Wenn wir mal von 500ms ausgehen, sind das gerade mal > 350kB. > Das ist deutlich wenigern als 2MB. Weil ich für jeden der Ziel-FIFOs der verketteten Listen in der Datei den Platz vorhalten müsste. Minimalanforderung sind 8 mögliche Ziel-FIFOs. So komme ich auf 256 kiB/FIFO mit einer ganz ähnlichen Rechnung. > Wie groß sind sie denn? Ich habe ca 128 kiB für die 8 FIFOs. Aufteilung zum Testen beliebig. >Und vor allem, wie ist der Gesamtaufbau der > Software? ISR -> CAN FIFO -> Thread zum interpretieren -> Datei FIFO -> Background Thread -> Datei > Ich hoffe mal, daß die CAN-Nachrichten per Interrupt gelesen und > verarbeitet werden und dann im FIFO landen. Ja, genau so. Threads/Tasks per RTOS. CAN FIFO Zugriff blockiert den Thread wenn dieser leer ist und dann kommt eben der Background Thread und pollt die FIFOs zum Schreiben der Datei. Der ursprüngliche Grund für die Wahl dieses Konzepts ist, dass die Daten aus den Interpreter Threads nicht nur in der Datei landen können, sondern zum kleinen Teil auch noch anderweitig weiterverarbeitet werden müssen. Mal sehen ob man die Daten vorher evtl. geschickter sortieren kann. > Threads sind dem zwar sehr ähnlich, aber da wäre ich vorsichtig, > Prioritäten und so. Das passt glaube ich schon, weil im Prinzip alles funktioniert. > Uhhhhh!!! Das Wort Blockieren ist gar nicht gut!!!! Ruhig, ruhig. Gäbe halt eine Semaphore damit der Background die Datei schreiben kann. Was soll ich machen? Entweder werden die Nachrichten verworfen weil der CAN FIFO voll ist oder weil der Datei-FIFO voll ist. > Der Trick ist halt, eben NICHT irgendwas zu blockieren, sondern alle > Tasks etc. müssen nur dann arbeiten, wenn es wirklich was zu tun gibt. > Damit werden die FIFOs auch optimal ausgenutzt. Siehe Multitasking. Ui, mit "blockieren" habe ich auf einen roten Knopf gedrückt? Ich meinte damit wie gesagt, den Interpreter-Thread zu blocken, damit der Background-Thread seine Daten loswerden kann. > Der SD-Kartenzugriff lief als normale Funktion in einer State machine in > der Hauptschleife, die DMX-Geschichte als State Machine in mehreren > ISRs. So ist das bei mir auch. > Da wurde nie irgendwas blockiert. Den externen SRAM von gut 56 kB > konnte ich voll für meine FIFOs nutzen, was bei SCHLECHTEN SD-Karten > auch nötig war, die hatten teilweise bis zu knapp 1s!!! Gedenkpause, > wenn man was geschrieben hat! > Das alles war einfaches, kooperatives Multitasking ohne RTOS und > Threads. In meiner kleinen Welt ist ein Interrupt die erste präemptive Ebene. Sogesehen also kein rein kooperatives Multi-Threading/Tasking. Der einzige Unterschied zu einem anderen Präemptiven Thread ist, dass sich die Hardware um das Scheduling kümmert und nicht das OS. Aber das soll mal nicht das Thema sein.
Dr. Sommer schrieb: > Nein, denn ich brauche zum Loggen kein fseek(). Es wird wie gesagt nur > kontinuierlich ein Stream geschrieben, Sprünge sind nicht möglich. Aha. Und wozu brauchst du dann überhaupt FAT ? Man kreiert in Windows eine Datei auf der Karte und schreibt dann einfach direkt in die Sektoren rein - einer nach dem anderen. Auf der Karte wird FAT wegen wear leveling am meisten rumgeschoben.
Hurra schrieb: > FRAM ist jetzt nicht so wunderbar. Das hat eine begrenzte Lebensdauer. > Jeder Lesezyklus (!) ist gleichzeitig ein Schreibzyklus. Danke für den Hinweis, das wusste ich noch nicht. Hab noch nie was damit gemacht, aber mit RAM habe ich keine begrenzte Lebensdauer verbunden. > Da wäre eher zu versuchen, das anders in den Griff zu bekommen: > - Nächstgrößeren Controller nehmen, mit mehr RAM > - Statt SPI SDIO verwenden > - schnellere SD-Karte nehmen > - Frequenz der SPI aufdrehen > - Statt SD-Karte ein NOR-Flash nehmen > Jetzt ist das NOR-Flash zwar nicht schneller, aber vorhersagbarer, was > das Timing angeht... SDIO ists eh schon. 4 Bit@24 MHz. Einer der Gründe für SD/eMMC ist, dass es gemanagt ist und man sich nicht auch noch um Wear-Leveling etc sorgen machen muss.
sind diese "min 8Ziel-FIFOs" so zwingend vorgeschrieben? Ist es nicht möglich alle Daten in einem FIFO zu halten und in eine Datei zu schreiben? Die Aufteilung müsste dan später (am PC?) erledigt werden. Dadurch hast du ein wesentlich bessere Schreib-Performance.
@Karl (Gast) >> Ich habe eine Implementierung geschrieben die 1 MByte/sec kontinuierlich >> auf eine Samsung Evo SDHC-Karte mit 64 KB RAM schreibt, natürlich in >> Dateien des FAT32-Systems, bei <1% CPU-Last. Bei Interesse könnte man >> über eine Lizensierung reden. >Mit kontinuierlich schreiben meinst Du streamen? Ja. >Hast du das Dateisystem selbst implementiert? >Garantierst Du das auch bei Beliebigem Zustand der FAT? >Garantierst Du das auch bei beliebigem fseek() innerhalb einer >fragmentierten 4 GiB Datei? Ich hab es damals mit dem berühmten FATfs von Elm Chan gemacht, das geht sehr gut. Der Trick ist dabei, die Datei vorher auf der Karte anzulegen und danach die Cluster link map table zu generieren. Damit kann man ohne FAT-Zugriff beliebig in der Datei rumspringen und schrieben/lesen. http://www.elm-chan.org/fsw/ff/en/lseek.html
Dr. Sommer schrieb: >> Garantierst Du das auch bei Beliebigem Zustand der FAT? > Nein, das ist quasi unmöglich. War eine Fangfrage :-) Daran habe ich mich noch nicht gewagt, klingt aber sehr vernünftig. Am besten noch gleich in der Größe einer Allocation-Unit der Karte, dann kann man die Blöcke vernünftig löschen. >> Garantierst Du das auch bei beliebigem fseek() innerhalb einer >> fragmentierten 4 GiB Datei? > Nein, denn ich brauche zum Loggen kein fseek(). Auch ein Test. Ich brauche leider fseek(). > Das sollten wir falls du noch Interesse hast lieber privat besprechen > ;-) Du kannst ja mal eine Mail-Adresse nennen... Für den Moment Danke. W.S. schrieb: > Da schreibt ein TO, daß irgendwelche Randbedingungen fest vorgegeben > seien und folglich indiskutabel - und jetzt kommt er mit der Lösung > seines Problemes nicht zu Potte und fragt deswegen hier an. Das ist Sinn und Zweck eines Forums? > So geht das nicht. Sehen wir noch... ;-) > Anstatt ein mechanisch winziges RAM zu suchen, > solltest du lieber über deine Randbedingungen nachdenken. Schmeiß sie > einfach über den Haufen und denke dir eine sinnvollere (weil > realisierbare) Lösung deines eigentlichen Problems aus. Man wird ja noch fragen dürfen, oder? Ist ja nicht so als hätte ich mir noch keine Gedanken gemacht und wollte alles vorgekaut bekommen. > Das ist weitaus sinnvoller, als mit Gewalt einer nicht tragfähigen Idee > nachzurennen. Da gebe ich Dir im Prinzip Recht. Es ist nun aber so, dass das zu schreibende Format (MDF4, für alle die es interessiert) feststeht. Nicht, weil es keine anderen und einfacheren Formate gäbe, sondern weil ich das schreiben will. Dampf T. schrieb: > [...] Muell. [...] > Erzaehl mal woher diese sinnlosen Anforderungen kommen. Nein. :-P > Der Poster hat etwas wenig Ahnung fuer > ein solches Projekt. Danke für die Blumen. Wo finde ich Deinen konstruktiven Beitrag zum Thema? > Wahrscheinlich ist man schon zeitlich im Verzug. Nein. Das ist ein internes Projekt ohne Deadline. Man nennt es "Forschung und Entwicklung", Horizont erweitern, schauen ob man was anders und besser machen kann (auch wenn es dadurch nicht einfacher wird). Falls daraus ein Produkt wird, umso besser.
Michael .. schrieb: > sind diese "min 8Ziel-FIFOs" so zwingend vorgeschrieben? > Ist es nicht möglich alle Daten in einem FIFO zu halten und in eine > Datei zu schreiben? Die Aufteilung müsste dan später (am PC?) erledigt > werden. > Dadurch hast du ein wesentlich bessere Schreib-Performance. Ja, das wäre möglich aber es ist eben das Ziel, dass keine Nachbearbeitung am PC erforderlich ist und die Messungen sofort verwendet werden können. (Aus eben jenem Grund muss das Ding auch FAT32 machen, obwohl es gewiss bessere Dateisysteme für den Zweck gibt. (Wenn man nicht gerade MTP verwenden möchte)) Falk B. schrieb: > Ich hab es damals mit dem berühmten FATfs von Elm Chan gemacht, das geht > sehr gut. Der Trick ist dabei, die Datei vorher auf der Karte anzulegen > und danach die Cluster link map table zu generieren. Damit kann man ohne > FAT-Zugriff beliebig in der Datei rumspringen und schrieben/lesen. Trifft sich gut, verwende ich auch. Hab das schon mal gelesen, damals aber offensichtlich nicht ganz kapiert. Schau ich mir nochmal an. Was mich abgeschreckt hat ist, dass man die Größe nicht ändern kann. Wenn ich das jetzt richtig verstehe gilt das aber nur so lange die CLMT aktiv ist. Sprich, wenn ich die Datei vergrößern möchte setze ich die CLMT auf 0, f_lseeke auf die neue Größe und lasse dann die CLMT neu berechnen? Klingt interessant, Danke!
Sehe ich das richtig, 8 Files gleichzeitig auf die Karte schreiben ? und deswegen brauchts den Seek ?
Oh D. schrieb: > Sehe ich das richtig, 8 Files gleichzeitig auf die Karte schreiben ? und > deswegen brauchts den Seek ? Nein nicht ganz. 8 Streams jeweils in Form einer verketteten Liste in eine Datei. Ich merk mir wahrscheinlich einfach den Sektor mit dem letzten Listenende damit ich den Seek zurück nicht brauche.
Eine Datei kennt keine verketteten Listen, nur Bloecke. Die Listen waeren dann eine Frage der Interpretation des Inhalter.
Eine Datei kennt keine verketteten Listen, nur Bloecke. Die Listen waeren dann eine Frage der Interpretation des Inhaltes.
@ Karl (Gast) >Nein nicht ganz. 8 Streams jeweils in Form einer verketteten Liste in >eine Datei. Dort liegt eines der Probleme. Auf diese Weise muss JEDER der 8 FIFOs im Extremfall die volle Zeit der SD-Karten Schreibverzögerung puffern, während die anderen gar nichts tun. Damit brauchst du den 8-fachen Speicher! Sinnvoller ist es, einen zusätzlichen FIFO zu schaffen, in welchem schreibfertige Pakete (z.B. deine 4kB) aus den 8 kleinen Einzel-FIFOs in den großem GesamtFIFO kopiert werden. Der kann dann groß sein und für ALLE Kanäle als Gesamtpuffer dienen. Dabei werden zwar alle Daten doppelt kopiert, aber das ist auf dem uC unwesentlich, erst recht bei 0,7MB/s. Deine CPU + RAM kann das 100 fache. >Ich merk mir wahrscheinlich einfach den Sektor mit dem letzten >Listenende damit ich den Seek zurück nicht brauche. Ich bin mir nicht sicher, ob das mit den online verketteten Listen und dem Schreiben des Zielformats unbedingt nötig und sinnvoll ist. Man könnte durchaus auch einfach alle CAN-Nachrichten + Zusatzinfos nacheinander in eine Zwischendatei schreiben und am Ende der Gesamtoperation daraus das endgültige Format herstellen. Damit kann man die Pufferanforderungen deutlich senken. Der doppelte Speicher ist im Zeitalter von 128GB++ SD-Karten nebensächlich.
Ich wuerd auch einen Thread, oder aequivalent, exklusiv auf auf die SD zugreifen lassen, und die Daten vorher zusammenfassen. zB jedes Packet mit einer Seriennummer, oder Zeitstempel versehen, und fertig. So sind locker das Zehnfache, dh 7 MB moeglich. Ohne Puffern und Muehe. Es ist so eigentlich ueblich : eine Resource, einen Thread, oder aequivalent.
:
Bearbeitet durch User
Falk B. schrieb: > Dort liegt eines der Probleme. Auf diese Weise muss JEDER der 8 FIFOs im > Extremfall die volle Zeit der SD-Karten Schreibverzögerung puffern, > während die anderen gar nichts tun. > Damit brauchst du den 8-fachen Speicher! Das meinte ich hiermit: Karl schrieb: > Bei genauerer Betrachtung lohnt es sich aber wahrscheinlich die CAN > FIFOs größer zu machen und die Auswerte-Threads so lange zu blockieren > bis in den Listen FIFOs wieder Platz ist, dann erspare ich mir für jeden > Listen FIFO den Worst-Case vorzuhalten. Falk B. schrieb: > Sinnvoller ist es, einen zusätzlichen FIFO zu schaffen, in welchem > schreibfertige Pakete (z.B. deine 4kB) aus den 8 kleinen Einzel-FIFOs in > den großem GesamtFIFO kopiert werden. Der kann dann groß sein und für > ALLE Kanäle als Gesamtpuffer dienen. Geht nicht, weil ich jeden der 4kiB Puffer in die richtige Liste schreiben muss, müsste ich sonst wieder getrennt verwalten. Könnte ich natürlich. Geht also doch. Oder übersehe ich was? > Dabei werden zwar alle Daten doppelt kopiert, aber das ist auf dem uC > unwesentlich, erst recht bei 0,7MB/s. Deine CPU + RAM kann das 100 > fache. Mach ich eh schon, weil der DMA Controller im STM32 nicht auf die 64 kiB CCM zugreifen kann, ich das CCM aber für die FIFOs brauche. Das geht fix. >>Ich merk mir wahrscheinlich einfach den Sektor mit dem letzten >>Listenende damit ich den Seek zurück nicht brauche. > > Ich bin mir nicht sicher, ob das mit den online verketteten Listen und > dem Schreiben des Zielformats unbedingt nötig und sinnvoll ist. Man > könnte durchaus auch einfach alle CAN-Nachrichten + Zusatzinfos > nacheinander in eine Zwischendatei schreiben und am Ende der > Gesamtoperation daraus das endgültige Format herstellen. Damit kann man > die Pufferanforderungen deutlich senken. > Der doppelte Speicher ist im Zeitalter von 128GB++ SD-Karten > nebensächlich. Jain. Möglich sicher, aber nicht Ziel des Ganzen. Die Messdateien werden auch in der Praxis gerne > 1 GiB, so dass das Erstellen des richtigen Formates im Nachhinein auch lange dauern würde. Jaja ich weiß, man kann es mir einfach nicht Recht machen ;-) Zwischenzeitlich habe ich probiert, einen ungenutzten Bereich der Karte als Zwischenspeicher zu verwenden, der vorab schön säuberlich gelöscht wurde. Maximale Schreiblatenz sinkt dadurch um ca 25%. Weniger als ich erhofft hätte :-( Als nächstes versuche ich den gemeinsamen großen FIFO und denke nochmal scharf über die fseek-erei nach...
Karl schrieb: > Zwischenzeitlich habe ich probiert, einen ungenutzten Bereich der Karte > als Zwischenspeicher zu verwenden, der vorab schön säuberlich gelöscht > wurde. Maximale Schreiblatenz sinkt dadurch um ca 25%. Weniger als ich > erhofft hätte :-( Interessanter Ansatz. Ist die Datenrate der 8 Kanäle konstant oder variabel?
Marcus H. schrieb: > Interessanter Ansatz. > Ist die Datenrate der 8 Kanäle konstant oder variabel? Vollkommen variabel zwischen 0 und maximaler Datenrate.
Karl schrieb: > Marcus H. schrieb: >> Interessanter Ansatz. >> Ist die Datenrate der 8 Kanäle konstant oder variabel? > > Vollkommen variabel zwischen 0 und maximaler Datenrate. OK - und wie lange liegt die maximale Datenrate am Stück an? Ich ziele darauf ab, dass Du die ankommenden Daten erstmal roh auf die SDcard schreibst. Und von dort, so denn Zeit ist, aufbereitest. Den Job könnte auch ein PC-Programm machen. Etwas optimieren kannst Du, indem Du direkt nach dem Formatieren eine "geeignet große" Containerdatei für den Datenpuffer erstellst.
@ Marcus H. (Firma: www.harerod.de) (lungfish) >Ich ziele darauf ab, dass Du die ankommenden Daten erstmal roh auf die >SDcard schreibst. >Und von dort, so denn Zeit ist, aufbereitest. >Den Job könnte auch ein PC-Programm machen. Das will er aber explizit nicht. >Etwas optimieren kannst Du, indem Du direkt nach dem Formatieren eine >"geeignet große" Containerdatei für den Datenpuffer erstellst. Das wurde schon empfohlen, er muss dazu auch nur die maximale Dateigröße vor dem Beginn des Schreibvorgangs in der Datei reservieren. Beitrag "Re: Räumlich kleines RAM mit mind. 2 MiB"
Falk B. schrieb: >>Etwas optimieren kannst Du, indem Du direkt nach dem Formatieren eine >>"geeignet große" Containerdatei für den Datenpuffer erstellst. > > Das wurde schon empfohlen, er muss dazu auch nur die maximale Dateigröße > vor dem Beginn des Schreibvorgangs in der Datei reservieren. > > Beitrag "Re: Räumlich kleines RAM mit mind. 2 MiB" Hier ging es mir darum, dass direkt nach dem Formatieren die Chance besteht, eine Datei zu erstellen, die fortlaufende Cluster hat. Die Optimierung wäre, dass man diese Datei am Filesystem vorbei benutzen kann. Aber häng Dich bitte nicht an dem Punkt auf, das läuft ja schon unter Optimierung der Optimierung.
Falk B. schrieb: > @ Marcus H. (Firma: www.harerod.de) (lungfish) > >>Ich ziele darauf ab, dass Du die ankommenden Daten erstmal roh auf die >>SDcard schreibst. >>Und von dort, so denn Zeit ist, aufbereitest. >>Den Job könnte auch ein PC-Programm machen. > > Das will er aber explizit nicht. Konnte ich so aus dem Thread bisher nicht explizit rauslesen.
@Marcus H. (Firma: www.harerod.de) (lungfish) >Hier ging es mir darum, dass direkt nach dem Formatieren die Chance >besteht, eine Datei zu erstellen, die fortlaufende Cluster hat. Stimmt, ist aber nicht kriegsentscheidend. >Die Optimierung wäre, dass man diese Datei am Filesystem vorbei benutzen >kann. Bringt kaum was, ist nur Hackermist. >Aber häng Dich bitte nicht an dem Punkt auf, das läuft ja schon unter >Optimierung der Optimierung. ;-) >>>Ich ziele darauf ab, dass Du die ankommenden Daten erstmal roh auf die >>>SDcard schreibst. >>>Und von dort, so denn Zeit ist, aufbereitest. >>>Den Job könnte auch ein PC-Programm machen. >> Das will er aber explizit nicht. >Konnte ich so aus dem Thread bisher nicht explizit rauslesen. Beitrag "Re: Räumlich kleines RAM mit mind. 2 MiB" "In welche der Listen eine Nachricht bzw. deren interpretierte Daten muss, entscheidet sich erst zur Laufzeit und soll absichtlich "online" erledigt werden." Beitrag "Re: Räumlich kleines RAM mit mind. 2 MiB" "Ja, das wäre möglich aber es ist eben das Ziel, dass keine Nachbearbeitung am PC erforderlich ist und die Messungen sofort verwendet werden können." Beitrag "Re: Räumlich kleines RAM mit mind. 2 MiB" "Jain. Möglich sicher, aber nicht Ziel des Ganzen. Die Messdateien werden auch in der Praxis gerne > 1 GiB, so dass das Erstellen des richtigen Formates im Nachhinein auch lange dauern würde."
Ich sehe hier vor allem eine Sammlung von nicht quantifizierten Wünschen. Der TO hat ein paar Vorschläge bekommen, nun kann er sich entscheiden, wie er Kosten, Bauraum und Geschwindigkeit zu einem, für ihn passenden, Gesamtpaket schnürt. Mit etwas Glück erzählt er uns sogar irgendwann, wie er das Thema umgesetzt hat.
Marcus H. schrieb: > eine Datei zu erstellen, die fortlaufende Cluster hat Ich glaube nicht, dass sich das lohnt - da eine Karte keine Köpfe bewegen muss wie eine Festplatte, dürfte die Lage der Cluster keinen Einfluss haben. Georg
Karl schrieb: > Hurra schrieb: > >> FRAM ist jetzt nicht so wunderbar. Das hat eine begrenzte Lebensdauer. >> Jeder Lesezyklus (!) ist gleichzeitig ein Schreibzyklus. > Danke für den Hinweis, das wusste ich noch nicht. Hab noch nie was damit > gemacht, aber mit RAM habe ich keine begrenzte Lebensdauer verbunden. Naja das ist Ansichtssache. Die Dinger von Cypress können 10^14 Scheib/Lesezyklen. Selbst wenn du es mit 40 MHz den ganzen Tag liest oder beschreibst hält das ding 43 (!!!!) Jahre. Problem ist hier vielleicht eher der Preis.
:
Bearbeitet durch User
Georg schrieb: > Marcus H. schrieb: >> eine Datei zu erstellen, die fortlaufende Cluster hat > > Ich glaube nicht, dass sich das lohnt - da eine Karte keine Köpfe > bewegen muss wie eine Festplatte, dürfte die Lage der Cluster keinen > Einfluss haben. Als ich diesen "Hackermist" vorgeschlagen habe, hatte ich nicht die Agilität der Schreib-/Leseköpfe der SDcard im Sinn.
Marcus H. schrieb: > Mit etwas Glück erzählt er uns sogar irgendwann, wie er das Thema > umgesetzt hat. Das wird noch ein wenig dauern. Für den Moment sehe ich folgende Ansätze die ich verfolgen möchte: - mehr FIFO vor der Interpretation der Daten und weniger danach spart einiges an Ram. Dabei tritt notgedrungen eine priority Inversion auf, weil der Thread zur Interpretation die höhere Priorität hat weil im Datenstrom auch in Echtzeit wünschenswerte Daten anfallen. Davon geht wahrscheinlich die Welt nicht unter aber das muss ich mir ansehen. - die unvorhersehbare Zeit eines fseek muss beschleunigt und konstanter gemacht werden. Da ich eine recht begrenzte Anzahl an Zielen habe dachte ich an einen fseek-cache. Mal sehen ob sich das in FatFs vernünftig integrieren lässt. Vorher Schau ich mir aber die Cluster Link Map tables noch an. - Last not least werde ich versuchen in der nächsten HW Revision ein PSRAM oder SDRAM unterzubringen bzw. Einfach mal den Platz für größeren Controller und RAM und Verdrahtung abschätzen. Evtl Wechsel auf bga Gehäuse vom Controller. Der stm32f405 ist in bga nur im Wlcsp mit 0.4 mm Pitch zu haben. Aber es gibt ja mittlerweile auch noch andere.
@Karl (Gast) >- mehr FIFO vor der Interpretation der Daten und weniger danach spart >einiges an Ram. Dabei tritt notgedrungen eine priority Inversion auf, >weil der Thread zur Interpretation die höhere Priorität hat weil im >Datenstrom auch in Echtzeit wünschenswerte Daten anfallen. Davon geht >wahrscheinlich die Welt nicht unter aber das muss ich mir ansehen. Klingt nicht so gut. >- die unvorhersehbare Zeit eines fseek muss beschleunigt und konstanter >gemacht werden. fseek ist nicht dein Problem, sondern der Schreibzugriff auf die SD-Karte. DORT können die bis zu 100-300ms Wartepause entstehen! fseek ist immer maximal schnell, wenn dabei nicht die Dateigröße verändert werden muss. > Da ich eine recht begrenzte Anzahl an Zielen habe dachte >ich an einen fseek-cache. Brauchst du nicht! > Mal sehen ob sich das in FatFs vernünftig >integrieren lässt. Vorher Schau ich mir aber die Cluster Link Map tables >noch an. Eben, dort ist das schon eingebaut. Fix und fertig!
Marcus H. schrieb: > Mit etwas Glück erzählt er uns sogar irgendwann, wie er das Thema > umgesetzt hat. Genau das habe ich jetzt vor. Ich bitte daher die Leichenfledderung zu entschuldigen. Evtl. Könnte ein Moderator den Titel des Threads umbenennen in "FAT32, SD Latenz und fseek()" oder ähnlich. Karl schrieb: > Für den Moment sehe ich folgende Ansätze die ich verfolgen möchte: > - mehr FIFO vor der Interpretation der Daten und weniger danach spart > einiges an Ram. Dabei tritt notgedrungen eine priority Inversion auf, > weil der Thread zur Interpretation die höhere Priorität hat weil im > Datenstrom auch in Echtzeit wünschenswerte Daten anfallen. Davon geht > wahrscheinlich die Welt nicht unter aber das muss ich mir ansehen. Diese Maßnahme hat die Sache insofern Verbessert weil der "CAN FIFO", der die Rohdaten der Nachrichten enthält nun für alle Streams gleichberechtigt genützt wird. Das Führt zu einer besseren, weil flexibleren Speichernutzung. In Zukunft wird noch ein größerer Teil der Arbeit im Idle-Task erledigt, weil damit auch die Konsistenz der (Meta-)Daten besser handhabbar ist. > - die unvorhersehbare Zeit eines fseek muss beschleunigt und konstanter > gemacht werden. Da ich eine recht begrenzte Anzahl an Zielen habe dachte > ich an einen fseek-cache. Mal sehen ob sich das in FatFs vernünftig > integrieren lässt. Vorher Schau ich mir aber die Cluster Link Map tables > noch an. Dieser Punkt war der wichtigste Teil der Lösung. Nachdem mich Falk auf die CLMT gebracht hat war das doch sehr inspirierend und ein Grund mich "etwas" näher mit FAT und der Implementierung in FatFs auseinanderzusetzen. Die CLMT macht im prinzip genau das, was ich brauch(t)e. Sie hat aber den für mich recht großen Nachteil, dass die Datei bei aktiver CLMT nicht wachsen kann. Allokation einer 1 GiB Datei dauert bei mir fast 3 s, was die Startlatenz entsprechend erhöht hätte. Zusätzlich gibt es keine Garantie, dass die CLMT bei einem maximal idiotisch fragmentierten Dateisystem in den vorhandenen Puffer passt. Das führte zu einem wrapper um f_lseek(), das den Datei-Pointer und den zugehörigen cluster cachet. Die Datei-Positionen zu denen ich zurückkehren möchte sind mir vorher einigermaßen bekannt, so dass derzeit die Verwaltung des caches manuell getriggert wird. Ergebnis: f_lseek() Zeiten wie mit CLMT ohne die für meine Anwendung störenden Nachteile. *Vielen vielen Dank für die Diskussion zu diesem Thema!!* Ohne diesen Hinweis wäre ich nicht (so schnell) draufgekommen. > - Last not least werde ich versuchen in der nächsten HW Revision ein > PSRAM oder SDRAM unterzubringen bzw. Einfach mal den Platz für größeren > Controller und RAM und Verdrahtung abschätzen. Evtl Wechsel auf bga > Gehäuse vom Controller. Der stm32f405 ist in bga nur im Wlcsp mit 0.4 mm > Pitch zu haben. Aber es gibt ja mittlerweile auch noch andere. Das hat nicht ganz funktioniert. Die nächste Version der HW bekommt einen STM32F7 im handhabbaren BGA mit 0.8 mm Pitch mit immerhin 512 kiB Ram aber ohne externes SDRAM. Featuritis an anderer Stelle hat mir den Platz geklaut :-( und :-) zugleich...
Uwe B. schrieb: > Die STM32L4+ haben sogar 640 kByte Ram... Und mehr als 640 kBytes braucht kein Mensch ;-)
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.