RAM-Baustein

[HaWe]

kannst du auf deinem Speicher dann Variablen zwischenspeichern und damit int-, float-, shift- und sort-Rechenoperationen durchführen, so als wären diese Variablen im "normalen" RAM abgelegt, insb. dann, wenn das on-board-RAM mit anderen Dingen bereits belegt ist?
Und wie sieht es mit Programm-Code aus?

[Moppi]

Die Anforderung ist ein Bussystem, an das mehrere Kontroller angebunden sind. Einer schaufelt Daten in einen Zwischenspeicher, die andern Kontroller bearbeiten die Daten gemeinsam und möglichst gleichzeitig. Die Ergebnisse sollen möglichst wieder in einem Zwischenspeicher abgelegt werden. Da ich noch 5 Datenleitungen übrig habe, könnte ich theor. 31 x 512KB Speicher-Module installieren. Ich hätte auch noch eine sechste Datenleitung, das wären dann theor. 63 RAM-Module oder bis 31MB Speicher. Wenn ich die übrigen 5 Adressleitungen einfach verwende, könnte man auf 5 Module zurückgreifen, oder 2.5MB Speicher.

Programmcode ist fest in den Kontrollern hinterlegt.

Ich Suche aber noch, wie ich das tatsächlich umsetzen will und letztlich muss (richtet sich nach den Möglichkeiten). Der RAM war der erste Schritt dazu. Weil ich eigentlich Speicher bräuchte, den ich ständig beschreiben kann, ohne dass der nach ein paar Wochen Schaden nimmt und ausfällt.

[HaWe]

ach soooo....! RAM Baustein klang für mich so als wenn du deinen Arbeitsspeicher (Rechen-, Programmspeicher) für einen kleinen AVR Arduino aufrüsten willst, daher mein Vorschlag, doch gleich einen leistungsfähigeren ARM Arduino mit von vornherein mehr RAM und Flash zu verwenden, ganz abgesehen von der vielfach größeren Rechenleistung.
Aber als Pufferspeicher für ein Netzwerk - das ist ntl was anderes...

[Moppi]

Was wäre eigentlich besser zu handhaben, sicherer in der Kommunkiktion und schneller: I2C-Bus oder die asynchrone serielle Schnittstelle?

Oha, da habe ich was gefunden: https://tronixstuff.com/2010/10/20/t...d-the-i2c-bus/

[HaWe]

UART ist schneller als I2C bei gleichem Bustakt, da bei I2C u.a. für die Daten immer noch zusätzlich Schreibaktionen für die Adressierug des/der Slaves nötig ist. Außerdem arbeitet I2C immer nur in 1 Richtung, also quasi half-duplex; UART kann hingegen prinzipiell full-duplex.
Weiterhin sind die Message-Puffer begrenzt, bei Arduino für I2C auf 32 Bytes, bei UART auf 64bytes, was für UART ebenfalls vorteilhafter ist.

Aber nicht alle Taktraten sind immer beiderseits möglich, so wird z.B. nicht überall ein hoher synchroner UART Takt von z.B. 400kHz-1MHz zwischen verschiedenen Geräten erreicht, und wenn auch meist 400kHz (full-speed) I2C Takt möglich ist, gilt dies auch nicht überall auf allen Plattformen auch für 1Mbit/s (Fast i2c) oder 3,2 Mbit/s (Highspeed I2C).

Die ARM-Prozessoren können z.B. locker Fast-i2c mit 1MHz, für AVRs gilt dies meist nicht.

Sieht man sich aber die schnelleren Standard-Taktraten für UART an:
115200 230400, 460800, 500000, 576000, 921600, 1000000, 1152000, 1500000, 2000000, 2500000, 3000000, 3500000, 4000000
so sind die auf einem Due auf deutlich unter 400kHz begrenzt ("230.4k just barely, maybe works, sometimes"),
auf AVRs geht es wegen der geeigneteren UART clock devider deutlich höher, da deren cpu-clock von 16MHz besser mit geringeren Fehlern heruntergeteilt werden kann als die 84MHz des Due oder die 48MHz des M0.

Mehrere Geräte mit multi-slave und auch multi-master sind dagegen eher mit I2C möglich.

Je höher die Taktraten und je länger die Kabel sind, entstehen aber exponentiell mehr Übertragungsfehler, die in jedem Falle duch Fehlerkontrolle wie checksums etc geprüft und die Daten dann ggf. verworfen werden müssen.

Nach meiner Erfahrung mit Raspis, ARMs und AVRs funktionieren zwischen allen (!) Plattformen gerade noch akzeptabel:
UART 115200 bis 230400 kHz, auf AVRs und Raspi auch bis mind. 1MHz
I2C mit AVRs bis 400 kHz, auf ARMs und Raspi auch bis mind. 1 MHz

- mit jew. Geschwindigkeitsvorteil für UART per full-duplex, ansonsten bei half-duplex (UART per Handshake) fast gleichwertig.

[Moppi]

Danke für die Infos, HaWe!

[HaWe]

gerne, np !

[Searcher]

Die Anforderung ist ein Bussystem, an das mehrere Kontroller angebunden sind. Einer schaufelt Daten in einen Zwischenspeicher, die andern Kontroller bearbeiten die Daten gemeinsam und möglichst gleichzeitig. Die Ergebnisse sollen möglichst wieder in einem Zwischenspeicher abgelegt werden.

Ich Suche aber noch, wie ich das tatsächlich umsetzen will und letztlich muss (richtet sich nach den Möglichkeiten). Der RAM war der erste Schritt dazu. Weil ich eigentlich Speicher bräuchte, den ich ständig beschreiben kann, ohne dass der nach ein paar Wochen Schaden nimmt und ausfällt.

Hallo Moppi,

ich habe noch mehrere W24M257AK-15 RAM Bausteine hier rumliegen. Ist ein 32K X 8Bit RAM und wird im Prinzip so angesteuert wie Dein 512kByte RAM.

Ich weiß zwar noch nicht wofür aber die Aufgabe mehrere Controller auf den RAM zugreifen zu lassen fand ich interessant und hat mich veranlaßt mit den 32kByte RAMs über die Realisierung nachzudenken.

Ich gehe davon aus, daß die Controller asynchron auf den RAM zugreifen können sollen. Und da bin jetzt soweit, daß ich glaube ohne einen bus arbiter, der den Aufbau komplexer macht, nicht auskommen zu können.

Hast Du auch einen eingebaut oder wie löst Du das Problem möglicher gleichzeitiger Buszugriffe?

Gruß
Searcher

[Moppi]

Das Mehrere Bausteine an denselben Bus angeschaltet sind, blieb mir auch nicht erspart. Ich musste Adress- und Datenbus zusammenlegen (nicht genug I/Os am Atmega328P-PU). Aber ich denke, die Programmierung richtet es dann. Meine Bausteine haben alle einen HIGH-Z-Zustand. Die Atmegas wohl auch, wenn man die auf Input schaltet. Ob sich da was stört weiß ich noch nicht. Nach einigem Probieren mit der seriellen Kommunikation, um Adressen zu übermitteln, habe ich das neu entworfen. Weil seriell zu langsam wäre. Funktioniert hatte das schon, mit einem Atmega328. Zu Anfang hatte ich nur einen Atmega, mit getrenntem Daten und Adressbus zum Speicher. Das war mir aber auch zu langsam, weil ich die Adressierung über Schiebregister machen musste. Dann habe ich versucht, 3 Schieberegister auf einmal zu laden, was auch ging, aber dann - erstaunlicher Weise - vom Programmcode her langsamer wurde, weil ich Adressen umrechen musste (das Schieben über die Schieberegister ging vom Code her dann schneller). Ich wollte gerne unter 1500 bis 2000 Millisekunden kommen, zum Lesen und Schreiben von 102400 Bytes. Als zentraler Speicher an einem Datenbus ist eine Beschaltung mit einem Atmega328 wegen begrenzter I/Os auch nicht tauglich, daher mein Versuch der ser. Schnittstelle, zur Adressübertragung. Außerdem hatte ich zu wenige I/Os, weil ich gerne noch SD-Karte einbinden möchte. Zwecks Ein- Auslagerung, wenn der physische SRAM zu wenig ist, weil höhere Adressen angefordert werden. Deshalb bin ich bei 2 Atmegas328 angekommen, die sich das dann teilen. Leider kann ich aber auch den Adressbus nicht vom Datenbus trennen (eben wegen der begrenzten I/Os), so dass dann das Umschalten der Pins zwischen Ein- und Ausgang nochmal Zeit kosten wird. Ich warte noch auf eine Lieferung meiner bestellten D-Latches, die ich eingeplant habe, dann fange ich mit dem Aufbau nochmal von vorne an.

Asynchroner Zugriff auf normales RAM ist nicht möglich. Dafür gibt es spezielle RAM-Bausteine, die das können. RAM-Zugriffe müssen in eine Warteschlange, bzw. muss jedes Modul, dass den RAM benötigt, warten. Hier kann man eine Hirarchielogik ausarbeiten. Da hatte ich gedacht, könnte man wenigstens einen RAM-Baustein spiegeln, damit man zwei Zugriffe gleichzeitig durchführen kann. Darum hatte ich an eine Schaltung gedacht, die am Atmega328 vorbei arbeitet und die Daten direkt von RAM zu RAM kopieren kann, so dass zwei Bausteine immer denselben Inhalt haben. Ich bin irgendwie auf eine Datenrate von ca. 16MByte/s gekommen - weiß nicht ob das richtig war, aber ich denk schon, da ein RAM nur 55ns Zugriffszeit hat. Nur das war mir zu aufgeblasen - ich hätte locker eine E100-Platine vollbekommen. Weshalb ich darauf zunächst verzichte. Verschiedene Arbeitsbereiche können natürlich ein eigenes RAM-Modul haben. So hat man verschiedene Scopes. Um Daten lokal zu verarbeiten und global auszutauschen. Das verringert die Wartezeiten.

[Searcher]

Mit asynchronem Zugriff meinte ich Controller, die frei entscheiden, wann sie Daten zum RAM senden bzw vom RAM holen wollen. Es könnte also zufällig passiern, daß gleichzeitig von verschiedenen Controllern auf die die Steuer/Adressleitungen des RAMs bzw der Schieberegister oder D-Latches? zugegriffen wird.

Um das zu verhindern dachte ich daran, den Controllern ein Zeitfenster zuzuordnen, in dem sie RAM Operationen durchführen dürfen. Aus Performancegründen verworfen, da eine ungenutzte reservierte Zeit einem anderen Controller verloren geht, der sie vielleicht gerade benötigt. Einen Arbiter, der den Buszugriff regelt in den Controllern selbst zu implementieren. Oder einen eigenen µC oder eine HW als Arbiter zu installieren - kleiner µC wie ATtiny24 meine favorisierte Lösung zur Zeit.

In etwa die"c) Independent request" Methode von dieser Seite
Über Datentransferrate habe ich noch gar nicht nachgedacht. Ein Mega328 kann mit 20Mhz getaktet werden. Ein ein Cycle Maschinenbefehl wird dann in 1/20MHz=50ns ausgeführt. zB ein OUT PORTB,r16. Die Daten müssen aber erst nach r16 gebracht werden. Ein zweiter Befehl ist da notwendig und noch weitere ...

Ich kann gar nicht abschätzen, wie schnell ein compilierter Arduino sketch ist. Ich nutze Bascom und da wo es schnell gehen soll oder es zeitkritisch wird mache ich Assembler Routinen.

Bin gespannt, wie es weitergeht und was das mal werden soll. Viel Erfolg!

Gruß
Searcher