Räumlich kleines RAM mit mind. 2 MiB

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

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.

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?

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.

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

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.

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?

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:
> 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.

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.

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.

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!

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.

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...

Marcus H. schrieb:
> Interessanter Ansatz.
> Ist die Datenrate der 8 Kanäle konstant oder variabel?

Vollkommen variabel zwischen 0 und maximaler Datenrate.

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

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.

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 ;-)