RAM-Baustein

[Moppi]

8-Bit programmierbare Zähler wären sinnvoll. Ich finde aber keine.

Das Problem mit dem Beschicken von Daten und Abholen von Daten, ist - finde ich - ein organisatorisches Problem. Auf die Verarbeitungsstruktur kommt es an. Das könnte man auf verschiedene Weise regeln, denke ich. Aber so weit bin ich noch nicht.

MfG

[HaWe]

ich würde ein sternförmiges Netzwerk wählen, bei denen 1 "Server" das RAM samt aller Zugriffe allein verwaltet.
Der Server kann dann per I2C rundrum alle "clients" abfragen, was sie zu melden haben, und dann die aktuellen r/w requests abarbeiten; dann kommt der nächste client dran.

Aus Performancegründen wäre dann aber sicher ein Server mit hohem Takt und großem onboard-RAM die beste Lösung, also ein M4 oder gar ein Raspi.

Sollten die Datenmengen deutlich größer sein oder werden oder auch erforderlicherweise nicht-flüchtig, könnte ein Raspi auch einen USB-Stick oder eine SSD etc. per USB verwenden.

[Searcher]

8-Bit programmierbare Zähler wären sinnvoll. Ich finde aber keine.

Es gibt 74HC161 (presetable 4-Bit binary counter), die kaskadiert werden können:
Wird im Datenblatt erwähnt und auch in https://forum.allaboutcircuits.com/t...8/#post-853339
Bin dort nicht registriert und bekomme den dortigen Schaltplan deswegen nicht in lesbare Größe

Ich vermute, daß Du den Zähler für die Adresseneingabe verwenden möchtest um nicht für jede Speicherstelle immer eine komplette Adresse vom Controller übertragen zu müssen, sondern einfach per Taktimpuls an den Zähler die Adresse erhöhen möchtest um damit den RAM sequenziell beschreiben/lesen zu können?

Wäre noch ein Stück mehr HW, die aber das Ding ein Stück schneller machen würde.

Gruß
Searcher

[Moppi]

Mit einem Zähler macht das durchaus Sinn. Denn das ist das, was man in der Regel bei der Datenverarbeitung macht: Adressen hintereinander auslesen.

Ich bin aus den 4 Bit Countern bisher nicht schlau geworden. Die ich gefunden hatte, waren Abwärtszähler. Man muss eine Andresse anlegen können und mit einem Taktimpuls den Zähler laden, der Stand erscheint am Ausgang und wird mit jedem Zähltakt erhöht - so sollte das sein.

Scheint so mit den 74HC161 zu funktionieren. Nur dass es hier 4-Bit Zähler sind. Macht dann bei 20 Adressleitungen 5 ICs. Da muss man dann schauen, wie der bautechnische Aufwand ist. Der Vorteil von Zähler-ICs ist, dass die um ein Vielfaches schneller zählen können und die Adresse muss nicht extra über Zwischenspeicher zum RAM übertragen werden, weil alles in einem Baustein schon drin ist.

Dann werde ich jetzt mal schauen, ob das Austauschen eines Atmega328 und zwei 8-Bit-Puffern, den Aufwand von zwei zusätzlichen ICs rechtfertigt.

Vielen Dank so weit, dafür!

MfG

[Manf]

8-Bit programmierbare Zähler wären sinnvoll. Ich finde aber keine.

Wenn solche gemeint sind:
https://www.google.com/search?client....0.3wnNNmUjr8o
http://www.ti.com/lit/ds/symlink/sn54as869.pdf

[Moppi]

Ich habe mal was zum 74HC161 zusammengebastelt. Zwecks Beschaltung und Verhalten:



Das war das erste brainstorming heute am Morgen. Ich weiß noch noch nicht, ob es so korrekt ist.

MfG


Nachtrag:

@Manf, gerade habe ich eine Bestelllung für die 4-Bit Counter getätigt - menno!
Allerdings Reichelt hat die 8-Bit Counter gar nicht. Conrad leider auch kein Treffer. Oder ich Suche falsch..

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

[HaWe]

wenn du nicht den "Schaffner" (Server) selber auch schreiben lassen willst, sondern der nur dazu da ist, eine "Fahrkarte" (Token) für die Zugriffsrechte zu vergeben und weiterzureichen, kann man auch einen "Token Ring" ohne Schaffner aufbauen. Hier reicht dann jeder Client, wenn er dran war und wenn er dann fertig ist, seinen Token an den nächsten im Netwerk-"Ring" weiter, sodass immer nur max. 1 den Token als Schreibberechtigung hat.
Aber ein Server, der die Tokens verwaltet, ist tatsächlich sicherer gegen Ausfälle und Störungen, das stimmt: es ist dann eine abgepeckte Variante meines oben skizzierten sternförmigen Server-Client-Netzes.
Beide Systeme können sich aber dennoch leicht aufhängen:
Der Token Ring, wenn irgendein beliebiger Client im Ring irgendwo ausfällt,
und im Stern, wenn der Server ausfällt.
Nur TCP/IP-Netze mit multiplen Knoten sind da ausfallsicherer.

[Moppi]

Die Teilnehmer untereinander zu verbinden, das wäre natürlich gut, weil man theor. beliebig viele miteinander verketten kann. Daran gefiel mir aber nicht, dass sich jeder Teilnehmer noch um die Absprache kümmern muss. Max. würde ich 2 Signalleitungen dafür verwenden, Eine rein und Eine raus, zum Nächsten. Bevor hier eine Entscheidung gefallen ist, muss das Signal alle Teilnehmer passiert haben. Außerdem kann man nicht ermitteln, ob ein im Ring weiter entfernter Teilnehmer, eher dran sein müsste, als andere.
Diese serielle Kommunikation gefällt mir irgendwie auf dieser Ebene nicht, ob I2C oder was anderes. Ich möchte möglichst kurze Latenzzeiten im System, sonst macht das für mich keinen Sinn - nur wenn ich eine bestimmte Datenverarbeitungsrate erreichen würde.

[HaWe]

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]

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?