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.
Larry schrieb: > Ein SRAM direkt geht nicht, weil die Leitungen nicht reichen. Naja.... Die Adressleitungen eines SRAM ließe sich per Zähler erzeugen
Larry schrieb: > 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. Larry schrieb: > 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? Larry schrieb: > 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.
Larry schrieb: > 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 Larry schrieb: > 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.
Larry schrieb: > 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... Ich tippe stark auf Troll.
Ob S. schrieb: > Mit 4GB Umfang und so schnell, dass sie nicht mit üblichen Speichermedien > zu erschlagen sein sollten... Vielleicht Messung der verzögerten Fluoreszenz, wo jedes registrierte Photon mit Timestamp im Speicher abgelegt wird ...
Worauf basiert den die Mikroprozessoreinheit? Ein PC-RAM-Modul hat dynamischen RAM. Dafür braucht deine Mikroprozessoreinheit eine Refresh-Logik.
Ob S. schrieb: > Messdaten aus Gewässerproben? 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.
Andreas M. schrieb: > nimmst Dir einen RPI 4 mit 4GB RAM oder mehr 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.
Larry schrieb: > Der war in der Diskussion, ist aber auch zu groß. Tja, dann ist Dein Projekt halt komplett unrealistisch und nicht umsetzbar.
Die Überlegung war folgende: 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.
Jörgen D. schrieb: > 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.
Larry schrieb: > Die Überlegung war folgende: > > 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.
Larry schrieb: > 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.
Larry schrieb: > 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: Larry schrieb: > Nachgedacht wurde über eine Flash-Disk, die aber zu langsam ist, weil > die Daten sehr schnell in Paketen kommen. denn wenn du 5 Leute nach "sehr schnellem" Speicher fragst, wirst du 10 verschiedene Antworten bekommen.
Ich würde einen Logic-Analyzer nehmen. 25 Mhz packen die doch locker.
Larry schrieb: > weil die Daten sehr schnell in Paketen kommen. Dann wird das mit der zu Verfügung stehenden Hardware eher nichts: > zu 10 Bit, der mit 25 MHz beschreibbar ist. Denn "sehr schnell" ist heutzutage irgendswas mit GBit/s aufwärts. > Wie ließe sich da ein RAM anschließen? Das Anschließen ist nur die halbe Schnitte. Das anschließende Ansteuern dieser 10 Leitungen wird die nutzbare Datenrate sehr effektiv begrenzen. Larry schrieb: > weil die Daten sehr schnell in Paketen kommen. 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
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch User
Bauform B. schrieb: > Compact Flash Karten Vielen Dank, das werde ich in Erwägung ziehen. Lothar M. schrieb: > 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.
Stephan S. schrieb: > 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. Die Erweiterung muss demnach sehr kompakt sein. J. S. schrieb: > 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. Link? "M-Ram" kenne ich nicht.
Larry schrieb: > Wir speichern davon etwa 10 Mbit durch Vorsortierung und speichern in > einem RAM von 1G, das etwa zu 70% frei ist. "Wir". Und welcher Microcontroller ist das, der da sagenhafte 1 G RAM haben soll? Wann kommt die nächste Salamischeibe?
Moin, Larry schrieb: > viel Blafasel 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. scnr, WK
Larry schrieb: > 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
Vielen Dank an die Helfenden. Wir werden das intern kommende Woche besprechen.
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.
Openlog? Max 115kbaud ist dann doch zu dürftig. Aber schmeißt die Vorverarbeitung halt raus. SD-Karten gibts auch mit 1TB
Larry schrieb: > 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?
:
Bearbeitet durch User
Larry schrieb: > Momentan etwa 50 Mit [...] > 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...
Beitrag #7510783 wurde von einem Moderator gelöscht.
Ob S. schrieb: > Das sind dann rund 80MByte/s. 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.
Ob S. schrieb: >> Das sind dann rund 80MByte/s. > > Das sollte natürlich 30MByte/s heißen. 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.
Larry schrieb: > Andreas M. schrieb: >> nimmst Dir einen RPI 4 mit 4GB RAM oder mehr > > 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!
Axel S. schrieb: > Entweder du legst alle Informationen offen oder du > trollst dich! Er trollt doch schon UNS! ;-)
Falk B. schrieb: > 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...
Andreas M. schrieb: > ... mit einem FPGA an Deinen Parallelport anbinden. Das wird es jetzt werden: Beitrag "Lattice iCE40 UltraPlus Bausteine" Offen ist noch, ob es ein RAM oder doch gleich eine Speicherkarte werden wird. Bauform B. schrieb: > 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?
Moin, Larry schrieb: > 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. Gruss WK
Larry schrieb: > Offen ist noch, ob es ein RAM oder doch gleich eine Speicherkarte werden > wird. FRAM ist schnell (bis 100 MHz) und nichtflüchtig. Mit GB wird es aber schwierig, die hören bei 2Mx8 auf.
Larry schrieb: > 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.
Andreas M. schrieb: > Kommt mir irgendwie alles unausgegoren vor. 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 Larry schrieb: > 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?
:
Bearbeitet durch Moderator
Falk B. schrieb: > "Die schnellste, und PREISWERTESTE Art, etwas zu tun, ist es gleich > richtig zu tun." > > Autor unbekannt du vergisst: "Wir haben keine Zeit es richtig zu tun aber jede Menge Zeit es mehrfach zu tun"
Moin, Larry schrieb: > Welche Alternativ FPGA-Familie ist empfehlenswert? Eine, die deinen Anforderungen gerecht wird. scnr, WK
Andreas M. schrieb: > 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.
Larry schrieb: > 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. >> nimmst Dir einen RPI 4 mit 4GB RAM oder mehr > Der war in der Diskussion, ist aber auch zu groß. Dann vergiss es. Kleiner kriegst du es wohl kaum hin. Larry schrieb: > 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. Nö
Larry schrieb: > Andreas M. schrieb: >> ... mit einem FPGA an Deinen Parallelport anbinden. > Das wird es jetzt werden: > Beitrag "Lattice iCE40 UltraPlus Bausteine" > > Offen ist noch, ob es ein RAM oder doch gleich eine Speicherkarte werden > wird. > > Bauform B. schrieb: >> 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
Joachim B. schrieb: > du vergisst: > "Wir haben keine Zeit es richtig zu tun aber jede Menge Zeit es mehrfach > zu tun" Arbeitest Du in der gleichen Firma wie ich? ;-)
Larry schrieb: > Welche Alternativ FPGA-Familie ist empfehlenswert? Ich bin raus. Komme mir endgültig verarscht vor.
Andreas M. schrieb: > Ich bin raus. Komme mir endgültig verarscht vor. Den Eindruck hatte ich schon am Freitag.
Rainer W. schrieb: > Früher (tm) könnten Daten und Adressen auch gemultiplext werden. Das ist das genau das, was mir spontan in den Sinn kam, daher der Vorschlag mit dem ALE. Stephan schrieb: >> - 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/ Da ist doch auch schon eine Flash Karte drauf.
Stefan F. schrieb: > Larry schrieb: >> 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. Andreas M. schrieb: > Ich bin raus. Komme mir endgültig verarscht vor. Niemand zwingt dich, bei Themen die dich nicht tangieren, mitzuwirken.
Lothar M. schrieb: > 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. Ja, oder eben direkt in ein größeres RAM. Stephan schrieb: > 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. J. S. schrieb: > wie z.B. Teensy Das sehen wir uns auch an.
Larry schrieb: > Niemand zwingt dich, bei Themen die dich nicht tangieren, mitzuwirken. Da Du Dich hartnäckig weigerst, auf Fragen einzugehen, bist Du hier der Troll. Du vergeudest Lebenszeit von hilfsbereiten Menschen.
Larry schrieb: > 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". > Es läuft also auf eine Aufsatzkarte hinaus, wie von Anfang an geplant. Mach so eine seligmachende "Aufsatzkarte" und löte darauf einen AVR und gib dem eine SD-Karte. Larry schrieb: > 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: - https://www.kampis-elektroecke.de/2019/05/avr-mit-einer-sd-karte-erweitern-teil-3/ 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?
Lothar M. schrieb: >> 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. Wurde das eingesetzte System schon genannt?
:
Bearbeitet durch User
Cyblord -. schrieb: > Wurde das eingesetzte System schon genannt? Nein, natürlich nicht, auch auf mehrere Nachfragen hin nicht.
Angehängte Dateien:
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): https://de.aliexpress.com/item/1005005834236063.html 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...
:
Bearbeitet durch User
Niklas G. schrieb: > Wenn du ein Board dieser Art verwendest Das ist dem Troll schon zu groß (denn es ist nur wenig kleiner als ein Raspberry Pi, der kategorisch ausgeschlossen wurde)
M. L. schrieb: > 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.
Harald K. schrieb: > Das ist dem Troll schon zu groß 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.
:
Bearbeitet durch User
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.
J. S. schrieb: > 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). J. S. schrieb: > Nur ist der H7 auch die zickigste Diva der STM32 Immer noch weniger Aufwand als ein FPGA-Design mit DDR2-SDRAM-Ansteuerung 😉
Larry schrieb: > 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.
Niklas G. schrieb: > Es hat auch ein paar riesige Steckverbinder und einiges an leerem Platz. Gewiss. > Wenn ein PCB-Design für einen FPGA im Budget ist, Ich habe starke Zweifel daran, daß der Troll sich dessen bewusst ist, was das bedeutet. Der frisst hier einfach nur Lebenszeit anderer Menschen.
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.
J. S. schrieb: > Zum Test eine 220 MB Datei gelesen Ja lesen ist immer schnell. Schreiben ist da ganz anders. Die billigen SanDisk Karten machen da manchmal 1sec Pause zwischendurch... J. S. schrieb: > und soviel Puffer haben die Kameras da sicher auch nicht. Einige MByte müssen sie definitiv haben, sonst geht es nicht.
M. L. schrieb: > Ja, oder eben direkt in ein größeres RAM. Ist dir eigentlich die Funktion eines RAM bewusst? Ist der Strom weg, sind die Daten weg. Gott schmeiß organischen Massenspeicher!
Andreas M. schrieb: > M. L. schrieb: >> Niemand zwingt dich, bei Themen die dich nicht tangieren, mitzuwirken. > Oh, der TE hat Verstärkung bekommen. Nein, er hat sich umbenannt. Mitten im Thread ist das schon ein wenig rücksichtslos. Larry schrieb: > in einer schwimmenden Tonne Das Design ist für die Tonne? So sieht es hier tatsächlich aus. Ich muss endlich mal was vergleichsweise Sinnvolles tun und geh jetzt raus, Heizöl sägen.
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?" A man can dream... 🙃
Mark B. schrieb: > Welche Informationen muss ich anderen geben, um die > Antwort auf meine Fragen zu erhalten? Das ist eine recht simple Rückkopplungsschleife. Wäre man kein Troll, würde man auf an einen gestellte Rückfragen eingehen und diese beantworten.
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.
:
Bearbeitet durch User
Harald K. schrieb: > Das ist eine recht simple Rückkopplungsschleife. > > 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!)
Mark B. schrieb: > Oder man könnte einfach direkt in der Themeneröffnung beschreiben: Tja, könnte man. Hast Du den Eindruck, daß das der Threadstarter gemacht hat?
Harald K. schrieb: > Tja, könnte man. Hast Du den Eindruck, daß das der Threadstarter gemacht > hat? Das hier: Mark B. schrieb: > Kann man nicht eine Art Schulung konzipieren soll ja allgemein für alle Threadstarter sein, nicht speziell für unseren Larry Spezialisten hier.
M. L. schrieb: > 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.
:
Bearbeitet durch Moderator
Michael L. schrieb: > Niklas G. schrieb: >> Wenn du ein Board dieser Art verwendest > > Das ist ein guter Hinweis - danke. Orange pi 2w ist kleiner und gibts mit 4gb
Wie schaut's aus, hat man mittlerweile einen Raspberry Pi verbaut in diesem ominösen Projekt? 🙂
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.