RAM-Baustein

HaWe · 27.09.2018, 10:53

ich fürchte fast, da hast du falsche Vorstellungen über die Geschwindigkeitsproblematik, denn ein Token hin oder her oder weiter zu reichen, das geht weit schneller als dann die Daten selber über ICs und GPIO Pins in dein externes RAM zu schreiben.
Da würde ich mal einen Geschwindigkeitstest machen, verschiedene große Datenpakete 1000x lesen und schreiben, mit chksum-Überprüfung!

PS,
du kannst auch 2x UART zur Kommunikation bei kleinen AVRs verwenden, einmal Serial() und einmal SoftwareSerial(), auch z.B. das eine für den Vorgänger und das andere für den Nachfolger im Ring (im Stern sicher eher I2C mit 400k) !

**Moppi** · 27.09.2018, 12:02

Das Maximum bei paralleler Datenübertragung, mit einem 16MHz Atmega328 konnte ich mit etwa 25 bis 27kByte pro Sekunde bestimmen

Wieviel ist es denn bei I2C mit einem 16MHz Atmega328?

HaWe · 27.09.2018, 12:23

habe ich mit Bytes noch nicht exakt getestet, aber als Hausnummer (!) bei 100kHz mit chksum Test auf master und slaves:
32byte-arrays jew. ca. alle 5ms, also 32*1000/5=6.4kB/s, bei 400kHz oder einzelnen Bytes sicher noch schneller (aber ntl. nicht mehr bytes, wenn du einzeln sendest).
Aber da gibt es sicher verlässliche, validierte Tests, wenn du es genau wissen willst. (Der Prozessortakt ist ja dafür nicht ausschlaggebend, nur I2C Bus-Takt.)
Ich meinte aber auch nicht nur die reine parallele Datenübertragung, sondern auch getestete physikalische Lese-/Schreibaktionen auf dem RAM, auch mit chksum Test.

**Moppi** · 27.09.2018, 14:02

Per I2C: 27kByte / Sekunde. Von daher wäre das gleich oder sogar etwas schneller, als mit einem Atmega328 parallel Daten zu übertragen.

sondern auch getestete physikalische Lese-/Schreibaktionen auf dem RAM

Der RAM benötigt ca. 55 bis 70ns, je nach Ausführung, dann ist es gelesen oder geschrieben, dann ist er damit fertig, inklusive allem, was er benötigt, um Daten abzulegen oder hervorzugraben und stabil zur Verfügung zu stellen.

Aber wenn ich Dich richtig verstehe, möchtest Du dann gerne zusätzlich noch einen Zusatz-RAM für Prüfbits dazupacken, bzw. am besten ganze Checksummen berechnen, beim Auslesen und Schreiben, und das dann überprüfen?
Bei einer Geschwindigkeit von unter 20MHz? Bei SRAM? Dann nehme ich an, wirst Du sicher auch bei andern Datenträgern immer ein Raid-System installiert haben?

HaWe · 27.09.2018, 16:36

Zitat von Moppi

Aber wenn ich Dich richtig verstehe, möchtest Du dann gerne zusätzlich noch einen Zusatz-RAM für Prüfbits dazupacken, bzw. am besten ganze Checksummen berechnen, beim Auslesen und Schreiben, und das dann überprüfen?
Bei einer Geschwindigkeit von unter 20MHz? Bei SRAM? Dann nehme ich an, wirst Du sicher auch bei andern Datenträgern immer ein Raid-System installiert haben?

Kein Zusatz-RAM, aber bei sensitiven Daten einen Check mindestens nach jedem Lesen, ggf auch Rückmeldung an den Sender wenn Daten fehlerhaft sind zum erneuten schreiben/senden.
Bei i2c, UART und BT habe ich immer ein Startbyte (255), dann ein chksum-Byte (sum ab 3.byte), by I2C dann die Slave-Addr, der Rest Datenbytes. Bei ungeschirmten, längeren Kabeln oder WL kommen oft unerwartete Fehler zustande.
Bei jedem Lesevorgang wird die chksum neu berechnet und mit der mitgeschickten chksum verglichen, erst dann weiterverarbeitet oder verworfen.
Fürs Schreiben wird nur die chksum berechnet und ins 2. byte hineingeschrieben, dann verschickt (geschrieben), der Empfänger prüft dann ja auf Konsistenz (bei dir notfalls immer zusätzliches zurücklesen zum Check, wenn es sensitive Daten sind).

Beruflich hatte ich aber tatsächlich ein hot-swap RAID System bei mir, das stimmt schon, hat aber vor allem was mit Ausfallsicherheit zu tun.

Dass paralleles Senden aber grundsätzlich schneller ist als serielles (bei gleichem Takt und gleich großen Datenpaketen), ist eigentlich doch kein Wunder, die Frage ist nur auch, wieviele Bytes einzeln oder gemeinsam bewegt und gecheckt werden müssen.

Wenn ich mit meinem Raspi allerdings auf SD Karte weniger sensitive Daten schreibe oder auch auf USB-HD, dann allerdings mache ich keine extra file-checks, das überlasse ich stillschweigend Linux.

**Moppi** · 27.09.2018, 23:30

Also der RAM wird mit 5 Volt betrieben, nicht mit 1.5 oder 2.3 oder 3.3 oder so. Die Kabel zu den Pins sind so dick, dass sie völlig überdimensioniert sind. Der Spannungsabstand zwischen High- und Low-Pegel so groß, die Leitungen kurz. BIs jetzt hatte ich noch keine größtmögliche Freuqenz beim Auslesen und Beschreiben. Ich hatte schon damit gerechnet, dass Bit-Fehler auftreten würden. Deswegen habe ich einen Memory-Check gebaut. Wenn Fehler auftraten, dann weil ich Programmierfehler gemacht habe oder Leitungen aus Versehen gezogen; manchmal wackeln welche mit den Steckverbindern. Aber bis jetzt bin ich erstaunt dass das gut funktioniert hat. Aber ob das Fehlerfrei bleibt, wird sich rausstellen, bin noch am experimentieren und haufenweise Zeichnungen erstellen (um mir über Vor und Nachteile bestimmter Schaltungen klar zu werden, weil auf einem Bild kann man viele Dinge doch besser erfassen und durchspielen). Bei den SD-Karten bin schon auf die Idee gekommen, schlussendlich mehrere zugleich zu betreiben, um Kartenausfälle durch Vergleichen der Daten frühzeitig zu erkennen. Aber jetzt werde ich erst mal demnächst Einiges löten. Für ein vorläufiges Schaltungskonzept habe ich mich erst mal entschieden, denke ich. Beim Vergleichen sind mir da auch Dinge aufgefallen, auf die ich von Anfang an hätte kommen können, weil sie eigentlich logisch sind. Deshalb hier nochmal etwas mehr:

Der RAM liefert 8 Bit parallel anliegend Daten. Die können nicht seriell übertragen werden, da er keine serielle Schnittstelle hat.
Die Daten müssen ausgelesen werden, indem eine Adresse gebildet und angelegt wird und dann die Steuerleitungen gesetzt werden, damit
die Daten am Ausgang anliegen oder vom Eingang geschrieben werden. Das geht nicht per serieller Schnittstelle.
Wenn die Daten beim Lesen anliegen, ist das oberste Ziel, Verzögerungen durch Folgekommunikation möglichst gering zu halten, bis dass
der eigentliche Datenempfänger die Daten abgeholt hat. Um eine serielle Schnittstelle dazwischen zu schalten, müssen die Daten
nochmal gelesen und zur ser. Schnittstelle geschickt werden. Dabei spielt keine Rolle, ob die Daten im Anschluss mit einer
womöglich höhren Geschwindigkeit weitergeschickt werden. In jedem Fall erhöht sich durch das Umlegen auf eine serielle Schnittstelle
die Bearbeitungszeit, bis die Daten beim Empfänger angekommen sind. Denn zu dem Zeitpunkt, wo die Daten umgeformt und verschickt
werden könnte sie der eigentliche Empfänger auch bereits abholen, indem er einen Portzugriff ausführt. Die Daten können physikalisch
nicht schneller beim Empfänger ankommen, als sie am Ursprung gewonnen werden können. Sie können allenfalls länger unterwegs sein, das
sind Verzögerungen, die sich summieren und ein System insgesamt ausbremsen.

Die Alternative wäre, auf einen großen Datenspeicher seriell zuzugreifen. Das kann ich mit meinem Netzwerkserver machen. Der hat die
entsprechende Leistung und Speicherkapazität und könnte sogar Berechnungen übernehmen oder sonst Daten verarbeiten. Mit ein wenig Java
lässt sich so etwas wunderbar lösen. Um Daten schnell zu übertragen, könnte ich auch nodeMCUs nehmen. Ich habe noch 5 Stück hier liegen.
Pro Board mit 80MHz getaktet, könnten sie parallel vom Netzwerk Daten laden, selbst be- oder verarbeiten oder hin übertragen.
Auch mit Java auf dem Netzwerkserver so weit kein Problem. Aber die Frage ist: ist das das Ziel, dass ich verfolge? Ist dies das, was mich interessiert? - Da ich solche
Sachen schon hier und da ausprobiert habe, fehlt mir dort an der Stelle die Herausforderung.
Oder nimmt man direkt ein Mehrprozessorboard, wo meinetwegen 10 Stück Intel Core i7 Extreme mit 3,4 GHz Taktrate drauf betrieben werden
- jeder Prozessor mit sechs Kernen, zwölf Threads und 15 MB Cache?

Dagegen bekomme ich für 150 Eur, 100 Stück Atmega328P-PU. Insgesamt eine Portzahl von 2000 Stück, bei 100 eigenständigen CPUs.
Also erstmal viel zum Ausprobieren ... was auch nicht zwangsweise jeder verstehen muss