Ich bearbeite ein BigData-Projekt, bei dem es um Massenspeicherung und Auswertung von Daten im Umweltbereich geht. Die Daten sind Messdaten aus Gewässerproben und werden mit einem Microprozessor über ein kompliziertes Gewinnungsverfahren erhoben.
Die Mikroprozessoreinheit bräuchte zur Datenpufferung und Zwischenspeicherung eine Art Speichererweiterung, am Besten mit einem PC-RAM-Modul. Etwa 4GB würden reichen.
Nachgedacht wurde über eine Flash-Disk, die aber zu langsam ist, weil die Daten sehr schnell in Paketen kommen. Der Controller hat leider auch kein IDE oder SATA oder USB, sondern nur einen Parallelport zu 10 Bit, der mit 25 MHz beschreibbar ist. Wie ließe sich da ein RAM anschließen?
Ein SRAM direkt geht nicht, weil die Leitungen nicht reichen.
Die Mikroprozessoreinheit bräuchte zur Datenpufferung und
Zwischenspeicherung eine Art Speichererweiterung, am Besten mit einem
PC-RAM-Modul. Etwa 4GB würden reichen.
Vergiss' es. Das bekommst Du schaltungstechnisch nicht in den Griff.
Nachgedacht wurde über eine Flash-Disk, die aber zu langsam ist, weil
die Daten sehr schnell in Paketen kommen.
Was heißt "sehr schnell"? Und warum sollten ausgerechnet Gewässerproben derartige Datenmengen produzieren?
Eine SD-Karte kann, wenn man sie im QSPI-Modus mit ausreichend hohem Takt ansteuert, bereits Schreibdatenraten > 50 MByte/sec verarbeiten. Das soll für Deine Gewässerproben /zu langsam/ sein?
Der Controller hat leider auch
kein IDE oder SATA oder USB, sondern nur einen Parallelport zu 10 Bit,
der mit 25 MHz beschreibbar ist. Wie ließe sich da ein RAM anschließen?
Gar nicht.
Du hast den falschen µC für Deine Lösung ausgesucht.
Nimm keinen µC, nimm einen Raspberry Pi. Den gibt es mit 4 und sogar 8 GByte RAM, an den kann man über die GPIO-Leitungen die gleiche Sensorik anschließen, die auch Dein µC verwendet, und dank USB bzw. des Netzwerkinterfaces bekommt man von dem die zig Gigabyte an Daten auch wieder runter.
Die Mikroprozessoreinheit bräuchte zur Datenpufferung und
Zwischenspeicherung eine Art Speichererweiterung, am Besten mit einem
PC-RAM-Modul. Etwa 4GB würden reichen.
4GB RAM Modul heißt mal mindestens DDR2-SDRAM. Den kannst Du dann
kein IDE oder SATA oder USB, sondern nur einen Parallelport zu 10 Bit,
der mit 25 MHz beschreibbar ist. Wie ließe sich da ein RAM anschließen?
... mit einem FPGA an Deinen Parallelport anbinden.
Oder du entsorgst die offensichtlich untaugliche, existierende Hardware und nimmst Dir einen RPI 4 mit 4GB RAM oder mehr, gerne auch als Computemodule und baust damit eine vernünftige Hardware.
Nachgedacht wurde über eine Flash-Disk, die aber zu langsam ist, weil
die Daten sehr schnell in Paketen kommen.
Wie schnell genau? Das ist der springende Punkt.
Etwa 4GB würden reichen.
Das ist kaum glaubhaft. Messdaten aus Gewässerproben? Mit 4GB Umfang und so schnell, dass sie nicht mit üblichen Speichermedien zu erschlagen sein sollten...
Es handelt sich um optische Daten aus Photosensoren und deren Spektren. Diese werden vorverarbeitet und mitgespeichert. Das eingesetzte Schaltungsmodul produziert das so. Die Testdauer ist da das Problem.
Wir könnten längere Meßphasen fahren, über z.B. die gesamte Nacht, wenn wir in der Läge wären, die Daten lokal im wassergeschützten Gehäuse zu speichern. Kabel zu einem Notebook ist keine Option, da Diebstahlgefahr und Problem mit Tiefe.
Der war in der Diskussion, ist aber auch zu groß. Es braucht ein kleines Platinchen mit RAM, das mit den 8, maximal 10 Bits auskommt. Ich hätte gedacht, dass es da etwas geben könnte.
Dann müsste man möglicherweise ein Flash mit schmalem Bus finden.
Die Prozessor-Moduleinheit hat 10 PortPins (weitere 6 sind vorhanden, aber belegt). Geschrieben wird in 8-Bit Worten, ich könnte es mit Maskierung nutzen, um nur die 2 Bits des unteren Wortes zu verwenden, wenn ich die alten 6 Bit lade und mitspeichere. Mit den beiden Bits könnte ich WR/RD und einen Schreibtakt steuern oder gültige Schreibdaten markieren. Das Flash-Karten-Protokoll hatte ich mir angesehen, scheint etwas komlizierter zu sein. Braucht offenbar eine Dateiverwaltung. Auf dem RasPI machen die das natürlich mit Leichtigkeit.
Da hat noch keiner nach dem Microprozessor gefragt, aber der ist Geheim
Wie so oft :-)
Wie auch immer: Ein einfaches FPGA bzw PLD mit 8 Bit Daten, einem ALE-Bit und einem DIR-Bit sollte reichen. Wenn das direction 1 ist, wird geschrieben ansonsten gelesen und eventuell angeliefertes Zeug ignoriert, wenn nichts gelesen werden sollte.
Mit dem ALE wird die Adresse übergeben, an die geschrieben werden soll. Das könnten z.B. 2 Bytes sein. Erweiterung: Ist das ALE aus, wird der interne Word-Pointer benutzt, der automatisch um ein Wort beim Schreiben und Lesen inkrementiert, so ähnlich wie das I2C macht.
Der PLD/FPGA sammelt die Daten und schreibt sie mit 16 Bit als ADR oder DAT weg. Das Streamen funktioniert natürlich nur, wenn man mit jedem Takt etwas Sinnvolles schreibt, um den Pointer zu nutzen. Ansonsten muss man eben immer erst eine ADR schreiben und ist entsprechend langsamer. Oder man sucht sich noch ein Bit für ein ausdrückliches OE.
Eine andere Option wäre die Benutzung eines SPI-Interfaces, wenn der Controller das haben sollte. Man überträgt dann halt gleich auf 8 Kanälen.
So ein FPGA kann alles zusammenbauen und auswerten.
Allerdings müsste man in beide Fällen klären, wie das RAM gelesen werden soll, wenn der Port auf Input geschaltet wird. Klappen kann das nur, wenn man das bitweise oder wortweise einstellen kann, damit nur die 8 Datenbits in der Richtung umgedreht werden.
Wenn es klein sein muss, könnte so ein Trenz-Modul der 0725er Serie interessant sein: Hat ein M-RAM drauf. Braucht aber Kenntnisse in der FPGA-Entwicklung. Das gilt dann auch für einen Speicherkontroller.
Irgendwie bin ich gefühlt auch der Meinung, dass es mit einer Flash-Speicherkarte gehen müsste.
Die Prozessor-Moduleinheit hat 10 PortPins (weitere 6 sind vorhanden,
aber belegt).
Bereits diese "Überlegung" zeigt, daß bei der Projektierung viel zu früh komplett falsch abgebogen wurde. Statt auf dem Parkplatz des gut ausgestatteten Baumarkts steht das Auto jetzt im Schlamm auf der Zufahrt eines Kartoffelackers, und der Feldweg dorthin war lang und mit vielen Kurven versehen.
Nachgedacht wurde über eine Flash-Disk, die aber zu langsam ist, weil
die Daten sehr schnell in Paketen kommen.
Aha, also "sehr schnell".
Du mußt schon die maximale Schreibrate angeben und wie lange die anliegt. Es könnte auch nur ein Burst sein, auf den lange Pausen folgen.
Bis jetzt hast Du zu den konkreten Anforderungen überhaupt nichts gesagt, nur ne Menge rumgeschwafelt.
Dann müsste man möglicherweise ein Flash mit schmalem Bus finden.
Also ist der Flash jetzt doch schnell genug?
Das erste was man braucht, bevor man überhaupt über Lösungen nachdenkt, sind konkrete Zahlen zu dieser Aussage:
Probieren wir es mal, wie es Ingenieure machen würden. Die packen "Gefühle" in "Fakten" und machen aus "sehr schnell" und "sehr viele" einfach numerische Werte und Datenraten. Also: wieviele Daten kommen da mit welcher Datenbreite wie schnell und wie oft in wie großen Paketen? Wie schnell kannst du diese Daten verarbeiten und wieder (ggfs. in der Datenmenge reduziert) weitergeben? Wieviele Daten musst du möglicherweise wie lange zwischenspeichern?
Finde jetzt einfach mal Antworten auf alle diese w*-Fragen
Reichlich unplausibel und alles nur geschwurbel statt konkreten Zahlen.
Aber 4GByte reichen für über die Nacht (also mind. 8 Stunden). Und die Daten kommen im Burst. Ok.
Und eine kurzzeitige Auswertung ist mit dem Controller anscheinend möglich, sonst ist die Fragestellung erstmal komplett falsch.
Aber 4GByte über 8 Stunden sind im Schnitt nicht mal 150kByte / Sekunde. Sollte quasi jeder 32bit-Controller easy schaffen.
Dateisystem brauchst du keines. Nur geht das Lesen dann halt auch nur mit zu deinem Format passender Software / Hardware.
Compact Flash Karten haben eine klassische IDE-Schnittstelle aka "True IDE". Die habe ich mal mit einem 8-Bit uC und diesen Signalen benutzt:
8 Bit Daten
3 Bit Register Select
Chip Select
I/O Read
I/O Write
Reset (hat man wohl sowieso irgendwo)
VCC, egal, ob 5V oder 3.3V
Das sieht doch so aus, als ob das mit 10 Pins und einem 6-Bit Latch funktionieren könnte. In der "CF+ and CompactFlash Specification" (damals Revision 1.4) ist alles genau beschrieben, inkl. den nötigen IDE-Befehlen.
Edit: man muss mindestens 512 Byte am Stück schreiben und lesen, besser mehr. Aber man braucht kein Dateisystem.
Also: wieviele Daten kommen da mit
welcher Datenbreite wie schnell und wie oft in wie großen Paketen?
Das ist noch nicht so ganz klar. Die Sensoreinheit wird über eine API gelesen, die ich nicht kenne. Ich sehe in meinem Teil nur die 32 Bit-Daten, die dynmisch übertragen werden.
Es kommen Frequenzwerte zu 16 Bit mit einer maximalen Frequenz von 8192 Hz, was wir einstellen können. Jeweils 2 Werte für Transmission und Reflektion, die Absorbtion wird berechnet. Momentan etwa 50 Mit aus insgesamt 7 Sensoren. Das System kann noch mehr anschließen.
Wir speichern davon etwa 10 Mbit durch Vorsortierung und speichern in einem RAM von 1G, das etwa zu 70% frei ist. Wir bekommen etwa 500 Messzyklen unter, was für z.B. 3h und alle 20 sec ein Bündel reicht.
Insgesamt ist die mittlere Bandbreite nicht sonderlich hoch, das ist richtig, weil nur impulsartig angenommen und ansonsten gerechnet wird. Die Schwierigkeit ist, in die SW noch eine umständliche Verwaltung für Datenspeicherung reinzubekommen, weil die Zeit wegnimmt. Es ist daher einfacher, man speichert die Daten in dem Moment weg, wo man sie im Prozessor hat, statt erst zu puffern und dann in einem anderen Prozess es langsam zu übertragen.
Ich würde einen Logic-Analyzer nehmen. 25 Mhz packen die doch locker.
Nein, ein externes Gerät geht nicht. Auch ein Notebook nicht. Schon ein Raspi ist zu groß. Das System stekt in einer schwimmenden Tonne, die mit Batterie versorgt wird.
Ein einfaches FPGA bzw PLD mit 8 Bit Daten, einem ALE-Bit und einem
DIR-Bit sollte reichen. ...
Wenn es klein sein muss, könnte so ein Trenz-Modul der 0725er Serie
interessant sein: Hat ein M-RAM drauf.
aber natuerlich wieder nicht die hier interessante Groesse:
Wieviele verfic*te MBit pro Sekunde ist die in dem gewuenschten System abs. max. anfallende Datenrate?
issesdennsoschwer?
Ob das Frequenzen, Transmissionen, Reflexionen oder sonstwas sind, ist doch voellig uninteressant, wenn's um ein Speicherinterface geht.
Momentan etwa 50 Mit aus insgesamt 7 Sensoren. [...] Wir speichern davon etwa 10 Mbit durch Vorsortierung
Also, wenn ihr "nur" 10 MBit/s bis 50 MBit/s speichert, dann wären doch Industrial µSD Karten genau das richtige! Klein und schnell genug. Alles andere ist doch Schmarrn! (4 GB SD-DDR RAM an 10 GPIOs hängen...)
Natürlich würde es helfen, wenn auf dem ominösen µC ein 4-Bit SPI Interface frei wäre. Aber selbst wenn es nur GPIOs sind, kommst du mit einem µSD Karte schneller ans Ziel als mit einem SD-DDR-Ram Modul. Die sind deutlich größer als eine µSD Karte. Und wenn schon ein RasPi zu groß ist. Bei Markenherstellern gibt's dann auch Datenblätter:
https://www.kingston.com/de/memory-cards/industrial-grade-microsd-uhs-i-u3
Wenn i2c oder rs232 implementiert werden können würde ich openlog verwenden. Fertig kostet es 10 Euro + Speicherkarte bei rs232.
Eventuell könntest du auch SW i2c oder was ähnliches mit der rs232 HW machen.
Es handelt sich um optische Daten aus Photosensoren und deren Spektren.
Diese werden vorverarbeitet und mitgespeichert. Das eingesetzte
Schaltungsmodul produziert das so. Die Testdauer ist da das Problem.
Ich fürchte eher, dass Messstrategie/Messfrequenz und Vorverarbeitung noch ungenutztes Optimierungspotential bieten. Wie hoch sind z.B. das SNR in den Daten oder die Korrelation aufeinanderfolgender Messungen?
Wir bekommen etwa 500
Messzyklen unter, was für z.B. 3h und alle 20 sec ein Bündel reicht.
OK, haben wir schonmal einen wichtigen Kennwert mit viel Mühe aus dir rausgeprügelt.
Insgesamt ist die mittlere Bandbreite nicht sonderlich hoch
Ganz genau. Selbst ohne jede "Vorsortierung" lächerlich und problemlos auf fast jede schrottige SD-Karte wegzuschreiben.
Was jetzt eigentlich nur noch fehlt, ist die Datenrate der "Bündel". Sie muss nach den bisherigen Einlassungen ("Speicher-Schnittstelle" mit 10Bit/25MHz) ja ganz sicher (sehr deutlich) unter 250MBit/s liegen, ansonsten wäre der Ansatz von vornherein vollkommen illusorisch.
Aber nehmen wir einfach mal die (ziemlich utopischen) 250MBit/s als gegeben an. Das sind dann rund 80MByte/s. Was bedeutet: Mit neuzeitlichen SD-Karten auch schon wieder recht problemlos erreichbar.
Die Schwierigkeit ist, in die SW noch eine umständliche Verwaltung für
Datenspeicherung reinzubekommen, weil die Zeit wegnimmt. Es ist daher
einfacher, man speichert die Daten in dem Moment weg, wo man sie im
Prozessor hat, statt erst zu puffern und dann in einem anderen Prozess
es langsam zu übertragen.
Genau. Man schreibt die Rohdaten ohne jede weitere Verarbeitung einfach direkt auf eine neuzeitliche SD-Karte und alles wird gut. Schnell genug, reichlich Platz und man filtert die Rohdaten nicht. Wer weiß, was sich in den gefilterten (und damit verlorenen) Rohdaten möglicherweise noch an Erkenntnissen verbirgt. So kann man später noch in Ruhe auch danach suchen...
Das sollte natürlich 30MByte/s heißen. Keine Ahnung, wie es zu diesem Fehler kam. Die Tasten für 3 und 8 liegen ja nun nicht gerade direkt nebeneinander. Vermutlich: "durch 8" noch im Kopf und statt des Ergebnisses auch direkt die 8 eingetippt.
Wenn gleich moderne SD-Karten sowas dauerhaft schreiben können, so kann es eine hemdsärmelige, handgeklöppelte Lösung mit 10 IOs mal sicher nicht. Denn auch so ein SD-Master braucht intern ORDENTLICH Puffer, um die gelegentlichen Schreibpausen der Karte zu puffern! Da reden wir hier mal fix von mehreren hundert Millisekunden.
"Die schnellste, und PREISWERTESTE Art, etwas zu tun, ist es gleich richtig zu tun."
Autor unbekannt
Man könnte über ein Raspberry Pi Zero nachdenken, der hat ne SD-Karte und ist sehr klein. Ob er ausreichend IOs für die Sensoren/ADCs hat, muss man prüfen.
Der war in der Diskussion, ist aber auch zu groß. Es braucht ein kleines
Platinchen mit RAM, das mit den 8, maximal 10 Bits auskommt. Ich hätte
gedacht, dass es da etwas geben könnte.
Tja. Da du nach wie vor nicht sagst, wie groß es denn sein darf, können wir dir nicht helfen. Auf 100 Iterationen von Vorschlag und Ablehnung hat hier keiner Lust. Entweder du legst alle Informationen offen oder du trollst dich!
Denn auch so ein SD-Master braucht intern ORDENTLICH Puffer, um
die gelegentlichen Schreibpausen der Karte zu puffern! Da reden wir hier
mal fix von mehreren hundert Millisekunden.
Sicher nicht bei aktuellen Karten, die in der Lage wären, 30MByte/s wegzuschreiben. Da sind die zulässigen Durchsatzeinbrüche beim Schreiben doch DEUTLICH enger spezifiziert...
Compact Flash Karten haben eine klassische IDE-Schnittstelle
Das hatten wir schon geprüft und befunden, dass die Schnittstelle zu kompliziert ist und die Pins nicht reichen. Das müsste dann der Zusatzbaustein tun.
Wie bekommt man da einen solchen IDE-Controller hinein?
Am Besten über den Umweg eines Soft-Prozessors, oder?
Das wird es jetzt werden:
Beitrag "Lattice iCE40 UltraPlus Bausteine"
Offen ist noch, ob es ein RAM oder doch gleich eine Speicherkarte werden
wird.
Wuerde ich wohl mal davon abhaengig machen, wie lange du die Daten speichern musst - und wieviel das ist und wie schnell das rein- und wieder rauskommen muss.
Offen ist noch, ob es ein RAM oder doch gleich eine Speicherkarte werden
wird.
Ein ice40UP+ hat gar nicht genug Pins um einen normalen SDRAM in der Größenordnung eures Speicherbedarfs anzusteuern. Der größte von denen hat 39 Pins:
bei 16Bit brauchts du mindestens 16+12+2+6 = 36 Pins Damit kommste aber höchstens bis 64MByte
bei 8Bit sinds zwar 9 Leitungen weniger, dafür brauchste noch viel mehr Adressleitungen um auf deine 4GB zu kommen.
Mit nem Hyperram kann man evtl noch ein paar Pins sparen aber da ist man auch noch weit weg von 4GB.
Und irgendwo willste ja auch noch deine 10 Leitungen vom Interface anschließen. Oder wie stellt Ihr euch das vor? Kommt mir irgendwie alles unausgegoren vor. Wenn eine Hardwae nix taugt, dann muss man halt in den sauren Apfel beißen und sie neu machen alles andere führt zu nix.
So sehe ich das auch. Da wird sich von einer Technologie, die keiner beherrscht oder detailliert einschätzen kann, das seligmachende Ergebnis erwartet.
Ist inzwischen eigentlich irgendwem klar, welche Datenraten als Burst und
im Mittel zu erwarten sind? Ich blicke bei den bisher angegebenen Werten nicht durch, dass ich irgendwas Belastbares daraus ableiten könnte. Das einzige, was mir sachdienlich scheint, ist das hier, wo
Wir speichern davon etwa 10 Mbit durch Vorsortierung und speichern in
einem RAM von 1G
Bit oder Byte?
das etwa zu 70% frei ist.
Bei RAM nimmt man üblicherweise Byte, somit habt ihr 700 MByte RAM was dann 5600 Mbit ergibt, was nach 5600 MBit / 10 MBit vermutlich zu der Aussage führt:
Wir bekommen etwa 500 Messzyklen unter
Und wenn das
für z.B. 3h ... reicht
dann habt ihr eine effektive mittlere Datenrate von 700 MByte/(3*3600s) = 64 kByte/s.
alle 20 sec ein Bündel
Sind dann vermutlich wieder die 10 MBit Pakete. Damit musst du doch nur die 10 MBit in ein RAM einlesen und dann in den folgenden 20 Sekunden ganz gemächlich auf eine SD schreiben. Das packt wegen der dafür nötigen 64 kByte/s jede noch so lausige SD oder MicroSD sogar im SPI-Modus.
Passen diese Betrachtungen? Falls nein: wo mache ich den Fehler?
bei 8Bit sinds zwar 9 Leitungen weniger, dafür brauchste noch viel mehr
Adressleitungen um auf deine 4GB zu kommen.
Mit 9 Adressleitingen mehr kannst du einen Faktor 512 mehr Adressen ansprechen. Das rechnet sich immer gegen einen Faktor 2 bei den Datenleitungen,
Früher (tm) könnten Daten und Adressen auch gemultiplext werden.
Es ist daher
einfacher, man speichert die Daten in dem Moment weg, wo man sie im
Prozessor hat, statt erst zu puffern und dann in einem anderen Prozess
es langsam zu übertragen.
Compact Flash Karten haben eine klassische IDE-Schnittstelle
Das hatten wir schon geprüft und befunden, dass die Schnittstelle zu
kompliziert ist und die Pins nicht reichen. Das müsste dann der
Zusatzbaustein tun.
Wie bekommt man da einen solchen IDE-Controller hinein?
Am Besten über den Umweg eines Soft-Prozessors, oder?
Ist ein RAM-Speicher dann nicht einfacher?
FPGA war glaub ich kein ernsthaft gemeinter Vorschlag für das Projekt.
Entweder SD Karte direkt oder seriell auf nen zweiten Controller und dann auf SD
Wie bekommt man da einen solchen IDE-Controller hinein?
Am Besten über den Umweg eines Soft-Prozessors, oder?
Ist ein RAM-Speicher dann nicht einfacher?
FPGA war glaub ich kein ernsthaft gemeinter Vorschlag für das Projekt.
Ohne FPGA wird es das nicht hinbekommen, es sei denn der Controller hat schon eine Schnittstelle. Mir fiele sonst nur ein, alles in I2C-EEproms zu jagen. Aber der Platz ... und programmieren muss man es immer.
Generell kann man das schon bauen, mit dem Speicher und ich würde auch ein RAM nehmen, allerdings müsste das ein SRAM sein, weil die Block-RAMs im FPGA zu wenige sind und auch dann braucht man FPGA Wissen. Von einem DDR-RAM würde ich als Anfänger mal gepflegt die Finger lassen.
SRAM ist zwar teuer und langsam, aber sehr einfach anzuschließen. Mit dem ALE-Trick kommt man auch mit sehr wenigen Leitungen hin. Mit 25MHz Zugriff sind das mit einem streaming Protokoll 8 Bit x 20MHz. Da reicht das langsamste SRAM.
Einen IDE-Controller ins FPGA zu setzen wäre aufwändiger.
Aber eine ganz andere Frage: Das Platinchen muss auch gebaut werden. Wie wäre es denn mit etwas Fertigem, wie z.B. Teensy / (FPPA).
https://ebics.net/teensy-fpga/
Kabel zu einem Notebook ist keine Option, da Diebstahlgefahr
Aber ein Spezial-Computer, der extra dafür entwickelt wurde, kostet ein
Vielfaches von einem Standard Laptop.
Es wird kein "Spezialcomputer" gebaut- es wird gar kein Computer gebaut. ???
Du hast das Problem nicht erkannt und die Aufgabe nicht gelesen. Es exisitiert eine kleine mobile Datenerfassungseinheit, die um Speicher erweitert werden soll.
Also scheiden Vorschläge wie die Hinzufügung eines 1-Platinen-PCs wie Raspberry oder ein Notebook völlig aus.
Sind dann vermutlich wieder die 10 MBit Pakete. Damit musst du doch nur
die 10 MBit in ein RAM einlesen und dann in den folgenden 20 Sekunden
ganz gemächlich auf eine SD schreiben.
Entweder SD Karte direkt oder seriell auf nen zweiten Controller und
dann auf SD
Natürlich wäre die Speicherkarte auch eine Lösung, aber ich sehe nicht, wie ich sie direkt an das bestehende System anbauen kann. Es läuft also auf eine Aufsatzkarte hinaus, wie von Anfang an geplant.
Es exisitiert eine kleine mobile Datenerfassungseinheit, die um Speicher
erweitert werden soll.
Genau das kann ein externer µC, den du über deinen "Datenbus" mit Informationen versorgst, super toll erledigen. Ich würde einen AVR und eine SD Karte und das Filesystem von Elm Chan nehmen und hätte die Speichererweiterung mprgen früh zusammengefädelt:
Das, was du mit dem FPGA und einem riesigen RAM vorhast, wird meiner Ansicht nach garantiert länger dauern und schlechter funktionieren. Du weißt schon, dass ein größeres DRAM einen ausgeschlafenen Controller braucht?
Natürlich wäre die Speicherkarte auch eine Lösung, aber ich sehe nicht,
wie ich sie direkt an das bestehende System anbauen kann.
Du musst sie ja nicht "direkt" an das System "anbauen".
Mir kommt das eher so vor als wüsste man gar nicht wie man irgendwas an dieses fertige Datenerfassungssystem anbauen könnte.
Für den TE scheint dies eine Blackbox zu sein.
Ich denke hier liegt das Hauptproblem.
Wenn du ein Board dieser Art verwendest/selber entwickelst, kann man da problemlos die Daten über einen (10bit-)Parallelbus empfangen und auf die SD-Karte speichern (nach "Core STM32H7" suchen falls der Link tot ist):
Datenraten von einigen MByte/Sec kontinuierlich sollten machbar sein (bei guten SD-Karten), als Peak kurzzeitig auch ein Vielfaches davon. Mittels eines eigenen PCBs kriegt man das auch noch kleiner hin. Einen FPGA braucht es da wirklich nicht...
Niemand zwingt dich, bei Themen die dich nicht tangieren, mitzuwirken.
Oh, der TE hat Verstärkung bekommen. Na fährt das Projekt grad gegen die Wand? Von wem aus eurem Team kommt eigentlich die beknackte Idee mit dem RAM, das diese hier so vehement mit Gewalt verteidigt wird? Lass mich raten: der ursprüngliche Entwickler ist fort und jetzt stehen lauter Leute ohne Ahnung von Tuten & Blasen rum und wissen nicht wie se's fertig bringen sollen. Der Arsch geht wohl langsam auf Grundeis.
Wenn ich schon solche Aussagen wie
"Vielen Dank an die Helfenden. Wir werden das intern kommende Woche besprechen."
"Offen ist noch, ob es ein RAM oder doch gleich eine Speicherkarte werden
wird."
"Das sehen wir uns auch an."
lese, dann bekomme ich eine ziemlich genaue Idee davon, was für Dampfplauderer da rumsitzen. Wie Lothar schon schrieb, Leute die Ahnung hätten, hätten das schon längst gelöst und zwar wesentlich einfacher und praktikabler.
Es hat auch ein paar riesige Steckverbinder und einiges an leerem Platz. Wenn ein PCB-Design für einen FPGA im Budget ist, ist die Entwicklung einer Mini-Version so eines Boards erst recht drin. Den Controller auf die eine Seite, den microSD-Slot auf die Rückseite, Spannungsregler, Quarz, FPC-Connector o.ä. dazu, fertig. So ein Fertigboard kann man halt zum Entwickeln/Testen nutzen. Das Schöne daran ist dass der Controller schon 1 MByte an SRAM enthält, so kann man viel puffern und eine hohe Datenrate erreichen.
Der H7 kann die SDC mit 20 MByte/s lesen und wahrscheinlich auch genauso schnell schreiben, die Karten können ja selber noch schneller.
Nur ist der H7 auch die zickigste Diva der STM32, da sollte man nicht meinen die SW mal eben von einem anderen System umschreiben zu können.
Der H7 kann die SDC mit 20 MByte/s lesen und wahrscheinlich auch genauso
schnell schreiben
An sich richtig, aber die Karten genehmigen sich lange Pausen, daher ist der Pufferspeicher für die Datenrate ausschlaggebend. Die 1 MByte sollte für eine einstellige MByte/Sec-Zahl reichen (muss man ausprobieren).
Nein, ein externes Gerät geht nicht. Auch ein Notebook nicht. Schon ein
Raspi ist zu groß. Das System stekt in einer schwimmenden Tonne, die mit
Batterie versorgt wird.
Die Erweiterung muss demnach sehr kompakt sein.
Manchmal muss man sich echt fragen. Eine Tonne von 10 l auf 100 l zu vergrößern ist sicher einfacher, als alles andere worüber hier philosophiert wird.
diese Datenrate habe ich selber an genau dem gezeigten Board gemessen. Zum Test eine 220 MB Datei gelesen, aber nichts weiter mit den Daten gemacht.
Es gibt ja verschiedene SD Klassen, auch für das Schreiben von Videodaten und soviel Puffer haben die Kameras da sicher auch nicht.
Kann man nicht eine Art Schulung konzipieren:
"Wie erstelle ich ein Thema richtig? Welche Informationen muss ich anderen geben, um die Antwort auf meine Fragen zu erhalten?"
Man könnte sogar einen ESP32S3 nehmen, der hat auch SDIO und einiges an Leistung. Auf den Modulen kriegt man massig PSRAM (8 MByte!) und das auch noch billig. Drahtloses Auslesen gibt's "gratis" dazu. Ich weiß allerdings nicht wie gut das SDIO-Interface nutzbar ist und ob man damit die Datenrate schafft.
Wäre man kein Troll, würde man auf an einen gestellte Rückfragen
eingehen und diese beantworten.
Oder man könnte einfach direkt in der Themeneröffnung beschreiben:
-Was bereits vorhanden ist an Hardware, Software, Dokumenten
-Was jetzt neu an Funktionalität dazukommen soll (das was, nicht das wie!)
Es exisitiert eine kleine mobile Datenerfassungseinheit, die um Speicher
erweitert werden soll.
Es existiert also eine Datenerfassungseinheit, die Euren Ansprüchen nicht genügt. Sie ist demnach untauglich für Eure Aufgabenstellung. Das Projekt ist damit ganz offensichtlich zum Scheitern verurteilt.
Nun willst Du das Scheitern des Projekts offenbar nicht wahrhaben und versuchst, dieses mit noch untauglichlicheren Ideen wie "RAM-Speichererweiterung" an einer gezielt geheimgehaltenen "Datenerfassungseinheit" zu retten. Du klammerst Dich also an einen Strohhalm, der so dünn ist, dass da nix mehr durchkommt. Du steckst also in einer Sackgasse.
Gib Dir einen Ruck und sieh ein, dass Du mit Deinen aussichtslosen Ideen die Karre nur noch weiter in den Dreck fährst. Dein momentanes Verhalten ist - aus meiner Sicht - auch nicht gerade fair gegenüber Deinen Mitstreitern, die zusammen mit Dir an diesem Projekt arbeiten.
Deshalb gebe ich Dir einen Rat:
Versuch, das Ding neu aufzuziehen. Manchmal muss man auch einen Schritt zurückgehen, um vorwärtszukommen. Sei offen für die Ideen anderer! Einige der Leser hier haben richtig viel Erfahrung, so dass sie Dir weiterhelfen können. Ignoriere deren Ideen nicht, ziehe sie stattdessen sorgfältig in Betracht. Diskutiere diese hier! Äußere Deine Bedenken! Akzeptiere ihre Argumente, statt sie von vornherein auszuschließen! Denke an Dein Ziel und schiebe Deinen bisher eingeschlagenen Weg dabei komplett in den Hintergrund! Sackgassen bleiben Sackgassen!
Beherzigst Du diesen Rat, kann da auch was draus werden. Und zu diesem Zweck hast Du Dich doch hier angemeldet und Dein Problem geschildert, nämlich um andere anzuhören!
Zum Thema:
Überdenke Deine untaugliche "Datenerfassungseinheit" und überlege, ob Du diese durch das oben erwähnte STM32H7-Modul mit SD-Karte ersetzen könntest. Hilfreich wäre die Nennung der Einheit, damit andere hier auch beurteilen können, ob sie überhaupt ersetzbar wäre. Wäre das STM32H7-Modul dann tauglich, sollte damit das System auch ähnlich klein bleiben und passen. Kleiner als ein RPI4 wäre es allemal. Bedenke auch, dass es noch den RasPi-Zero gibt, der noch wesentlich kleiner als ein RPI4 ist. Achja, ich kenne die verfügbaren Maße in der Tonne nicht, offenbar habe ich da was in Deinem Eröffnungsposting überlesen. Sorry dafür.
