RAM-Baustein

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?

**Searcher** · 27.09.2018, 15:14

Zitat von Moppi

@searcher, was die Koordination der Zugriffe angeht, habe ich mir gestern Abend noch Gedanken gemacht. Das Einfachste wird sein, wenn sich alle "Teilnehmer" bei einem "Schaffner" mit einem Signal (Pin log. 1 / log. 0) anmelden und von dem "Schaffner" dann eine Signalrückmeldung kommt, dass sie mit dem Bus fahren dürfen (Signal log. 1) oder noch nicht (Signal log. 0). Wenn ein "Teilnehmer" mit dem Bus gefahren ist, meldet der sich beim "Schaffner" mit log. 0 und der "Schaffner" geht dann zum nächsten "Teilnehmer", der sich angemeldet hat und erteilt ihm dann die Erlaubnis, mit dem Bus zu fahren. Je nach Konzept könnte der "Schaffner" auch eine gültige Fahrkarte verlangen, bevor er jemanden mit dem Bus fahren lässt.

Ja, so oder so ähnlich würde ich das auch machen. Das ist der Fall c auf der Seite, die ich vorher schon mal verlinkt hatte: http://www.ques10.com/p/8794/what-is...wo-techniques/
Da gibt es noch einen gemeinsame Bus Busy Leitung. Ist mir im Augenblick unklar, ob die wirklich gebraucht wird.

Schade wg. den chip Vorschlägen von Manf. Als Versender fand ich bei einen für mehr als 8€

das Stück. Wird anscheinend kaum noch verwendet.

Gruß
Searcher

**Moppi** · 27.09.2018, 15:24

So, nun hatte ich mich auf hohe Übertragungsraten gefreut und nun das:
Bei Byteweiser Übertragung mit I2C, sinkt die Übertragungsrate auf ca. 11.5KByte/s. Wo ich bei paralleler Übertragung über die I/O-Ports schon mit 22kByte rechnen könnte. Für I2C muss dann das Prozedere geändert werden. Denn eigentlich könnte man jetzt die 8-Bit-Daten über 2 Pins übertragen. Aber beim Steuerbus bin ich der Meinung, dass die Anbindung über dig. I/O-Ports schneller ist, weil man da nur einzelne Bits als Informationen benötigt. Über I2C würde man dafür eine Datenrate von schätzungsweise über 200kByte/s benötigen, um die relevanten Informationen in der selben Zeit zu übertragen.

@searcher, diese 8-Bit-Zähler sind schwer zu bekommen. Übrigens gab es bis vor kurzem noch 1MByte SRAM bei Reichelt. Das ist eine gute Woche her. Die sind auch vorerst ausgestorben. RS Components hat die momenatn auch nicht.
Ich habe mir das so genau nicht angesehen, was Du verlinkt hattest. Aber ein Busy-Signal ist schon notwendig, wenn man Aufgabenteilung betreibt. Der eine muss ja wissen, ob der andere schon fertig ist, damit z.B. die gemeinsam erarbeiteten Daten auf den Bus gelegt werden können. Oder auch, wenn man Sender und Empfänger synchronisieren möchte.

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

HaWe · 28.09.2018, 08:27

Klingt äußerst ambitioniert...

Was und wieviel in welcher Zeit um alles in der Welt aber willst du denn da eigentlich speichern?

**Moppi** · 28.09.2018, 13:49

Bis jetzt hatte ich keine Datenblöcke größer 8MB. Bei komplexeren Zusammenhängen könnten es aber auch mehr werden. Es geht erst mal nur um String-Verarbeitung: Splitten, Ersetzen, Suchen. Theoretisches Beispiel: Damit könnte man, in jeder beliebigen Sprache, Sätze bilden. Damit könnte man dann wiederum gespeicherte Daten, die untereinander zusammenhängen, in Sätzen beschreiben. Was man dabei als Sprache definiert, ist der Fantasie überlassen. Ist im Grunde erst mal nur eine Aneinanderreihung beliebiger Zeichen, die einem Muster oder Regeln folgt. Als Software habe ich fertig.

Aber jetzt will ich wissen, ob ich das als Hardware bauen kann. Einfach der Unabhängigkeit von bestehenden Betriebssystemen und anderer Software wegen. Geschwindigkeit: weiß ich noch nicht. Erstmal sehen, wie schnell welche Einheit am Ende sein muss, um im Verbund, der ja noch gar nicht da ist, eine brauchbare Geschwindigkeit zu erzielen. Aber ich sag mal so: wenn mein PC einige Sekunden oder Minuten benötigt und die Gesamtschaltung dann ein paar Stunden oder Tage, dann stimmt was mit der Geschwindigkeit nicht.