RAM-Baustein

[Moppi]

Der Speicher ist angekommen. Nun kann's ans Probieren gehen.

[Searcher]

Der Speicher ist angekommen. Nun kann's ans Probieren gehen.

Hallo,
wie heißt er denn?

Gruß
Searcher

[Moppi]

K6x4008c1f

[HaWe]

habe jetzt auch mehr RAM und Flash:
512 KB flash, 192 KB RAM
auf einem ARM Cortex M4: Adafruit Feather M4 für Arduino IDE, 120MHz mit single-fpu
Preis 23 EUR, was auch nicht die Welt ist.

Aber mannomann, was ein Geschoss!
Ganz abgesehen vom Programm- und Variablenspeicher, auch die Rechenleistung ist immens:
int und double sind hier schon irre schnell, aber float schießt echt den Vogel ab!

Der Feather M4 hat etwa Nano-Größe, gibts aber auch etwa wie Micro (Itsybitsy M4) und auch wie Uno-Board-Größe (Metro M4).
Da lohnt sich der Speicher!

[Moppi]

So. Funktionieren tut das jetzt mit dem Speicher, am Arduino. Adressierung über Schieberegister 74595. Da sich der Uno bzw. ATmega328P-PU mit 20 I/O-Leitungen konfigurieren lässt, habe ich jetzt parallele Dateneingabe realisiert und kann die Geschwindigkeit bei der Adressierung noch etwa verdoppeln, indem ich jedes Schieberegister extra mit Daten beschicke. So kann man die Daten an 3 Registern gleichzeitig anlegen und muss insgesamt nur neun mal takten, um die 19 Bit-Adressdaten am Ausgang zu haben. Das Schieben der Adressbits über die 74595 nimmt mit am meisten Zeit in Anspruch. Leider muss man beim Verknüddeln der Leitungen höllisch aufpassen. Trotzdem ich mir sehr viel Mühe gab, habe ich dennoch zwei benachbarte Steuerleitungen am CMOS-RAM vertauscht, was zu unerwartetem, nicht erklärbaren Verhalten führte. Aber sonst funktioniert das ganz respektierlich, bis jetzt - letzter Stand - problemlos.

[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.