RAM-Baustein

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

[HaWe]

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]

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]

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

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.