RAM-Baustein

[Moppi]

Ich muss gestehen, dass ich einem Rechenfehler unterlegen war. Denn ich habe dieselben Daten ermittelt: ca. 10µs für eine 15(16)Bit Adresse. Ich kann es auf evtl ca. 8µs drücken. Da bin ich mit Deinen Werten erst mal ins Straucheln gekommen. Allerdings ist es schon so, dass ich in dieser Zeit schon 2mal 8 Bit übertrage. Daher kann man nicht von kByte sprechen, weils ja Worte sind. Also in kByte wär's ja schon das Doppelte (250kByte). Wundern tu ich mich jetzt etwas über diese SPI-Anbindung. Ist dem Atmega dort jegliche Rückmeldung egal? Einfach nur Daten drauf und Takt? - Bemerkenswerter Ansatz. Dann bekommst Du die Daten über SPI auch rein? Kannst Du den Atmega nicht höher takten, nicht mit 20MHz? Wenn Du auf SPI 250KByte/s Daten übertragen willst, muss der Takt per SPI ja th. irgendwo bei 250*1024*8 liegen = 2048kHz.

Mit dem Aufbau ist es in der Tat bei mir etwas anders. Ich übertrage in etwa: 1 Byte, für den Modus (Lesen/Schreiben/Adressieren) und warte noch eine Rückmeldung ab, ob die Daten bereit stehen, bzw. übernommen wurden. Da geht schon einiges hin und her, bevor ein Byte übertragen ist.

MfG

PS: Deine Sammlung meiner "Werke" finde ich echt stark! Simple aufgebaute Dinge, die funktionieren. Wenn man sich dann anschaut, womit Du das gebaut hast ... Du kannst Spielzeugentwickler werden und viel Reichtum damit in den USA machen, Haua-ha! Ich seh schon ... "Searcher-Toys" und die Kinder laufen die Bude ein.

[Searcher]

Wundern tu ich mich jetzt nur noch etwas über diese SPI-Anbindung. Ist dem Atmega dort jegliche Rückmeldung egal? Einfach nur Daten drauf und Takt? - Bemerkenswerter Ansatz.

Ja, genau. Es sei denn Bascom macht noch irgend etwas, das ich nicht weiß. Der SPI Master teilt doch nur mit SS dem Slave mit, daß da was kommt. Das Byte, das gesendet werden soll, sollte im Senderegister stehen und wird dann durch die Hardware rausgetaktet. Vielleicht programmiere ich das irgendwann auch noch zu Fuß aber im Augenblick läuft das mit den unten stehenden Bascom Befehlen. Ob der Slave Daten zurückgibt ist in diesem Fall egal. Es soll ja nur die Adresse des zu übertragenden Datenbytes zu den 74HC595ern gelangen. Wenn der RAM Baustein eingebaut ist, soll vom Mega88 über einen Port das Datenbyte angelegt werden und mit einer WRITE Signal/Leitung in den RAM übernommen werden.

Meine Schaltung ist von hier abgekupfert: https://rn-wissen.de/wiki/index.php?...AVR#Schaltplan
mit einem zweiten 74HC595 in Reihe. (und ohne die Widerstände - kommt noch, wenn ich Probleme entdecke - bis jetzt geht es ohne)

Messung mit Oszi zur Adressübertragung mit diesem Programm. Bei Tastendruck werden zwei Byte übertragen.

$regfile = "m88pdef.dat"
$framesize = 32
$swstack = 32
$hwstack = 32
$crystal = 8000000

Config Spi = Hard , Interrupt = Off , Data_order = Msb , Master = Yes , Polarity = Low , Phase = 0 , Clockrate = 4 , Noss = 0
Spsr.spi2x = 1                                              'double spi speed for master
Spiinit

Ddrb.2 = 1                                                  'SS as output
Portb.0 = 1                                                 'activate pullup for button

Dim A(8) As Byte
Dim Counter_a As Byte

Counter_a = 1
A(1) = &B0000_0001
A(2) = &B0000_0010
A(3) = &B0000_0100
A(4) = &B0000_1000
A(5) = &B0001_0000
A(6) = &B0010_0000
A(7) = &B0100_0000
A(8) = &B1000_0000

Do
  Debounce Pinb.0 , 0 , Shift_byte_out , Sub                'waits for button activation
Loop
End                                                         'end program

Shift_byte_out:
  Spiout A(counter_a) , 2                                   'sends two bytes of array A out of SPI Interface
  If Counter_a > 6 Then Counter_a = 1 Else Counter_a = Counter_a + 2
Return

Dann bekommst Du die Daten über SPI auch rein?

Nein. Daten sollen direkt über den Datenbus von einem Port am µC zum RAM gehen und über den gleichen PORT vom RAM gelesen werden. Nur die Schreib/Leseadresse geht bei mir per SPI über die Schieberegister zum RAM.

Kannst Du den Atmega nicht höher takten, nicht mit 20MHz?

Ich könnte auch höher takten allerdings muß ich dann noch 'nen Quarz/e rauskramen und anbauen. Zum Testen reicht mir erstmal der interne Oszillator. Ich habe ja keine konkrete Anwendung wie Du, sondern schaue mal, wie weit ich komme.

Es kann auch sein, daß ich irgendwo einen fatalen Konzeptfehler habe, da ich erst baue und nicht so weit denke

PS: Deine Sammlung meiner "Werke" finde ich echt stark! Simple aufgebaute Dinge, die funktionieren. Wenn man sich dann anschaut, womit Du das gebaut hast ... Du kannst Spielzeugentwickler werden und viel Reichtum damit in den USA machen, Haua-ha! Ich seh schon ... "Searcher-Toys" und die Kinder laufen die Bude ein.

Danke!

[Moppi]

Wo der über die Banane fährt (oder nur die Schale) find ich echt zum schreien, sieht irre aus, wie der schnurgerade drüberfährt.

Ja, die SPI-Schnittstelle hatte ich noch gar nicht im Hinterkopf, die habe ich noch nicht mal ausprobiert. Wenn ich das richtig nachgelesen habe, kann die auch mit einigen MHz arbeiten. Das ist schon interessant! Weil damit Parallel-Seriell und andersrum kein Thema ist. Wie sieht das denn dann mit den max. Kabellängen bei SPI aus? Letzten Endes müssen die Daten ja aber auch wieder irgendwo abgeholt werden, womit wir dann wieder zum Thema Netto-Datenrate kommen, eben das, was an einem bestimmten Punkt im Programm ankommt, dass es auch verarbeitet werden kann.

[Searcher]

Wo der über die Banane fährt (oder nur die Schale) find ich echt zum schreien, sieht irre aus, wie der schnurgerade drüberfährt.

Bei Youtube kann man ja nachsehen, von wo aus es die meisten Zugriffe gab. Da war "Ein erster Linienfolger ohne µC" in Indien sehr populär. Keine Ahnung wie der da hin kam

Ich hatte in den Blogs auch mal ein Bitbanging (falls die Bezeichnung hier zutrifft) Protokoll einer seriellen Datenübertragung im Zwangslaufverfahren über zwei Adern entwickelt. Da wird jedes Bit einzeln quittiert. Ist also nicht vom Takt abhängig. Die Übertragung kann unterbrochen und wieder aufgenommen werden. Erreichte, glaube ich nur 400000 Bit/s bei 16MHz Systemtakt da nicht HW unterstützt. Keine Ahnung ob Du das brauchen kannst. Hier der Link

Ja, die SPI-Schnittstelle hatte ich noch gar nicht im Hinterkopf, die habe ich noch nicht mal ausprobiert. Wenn ich das richtig nachgelesen habe, kann die auch mit einigen MHz arbeiten.

Ja. Der SPI Takt läst sich auf halben Systemtakt konfigurieren. 20MHz Systemtakt - 10MHz SPI Master Takt.

Wie sieht das denn dann mit den max. Kabellängen bei SPI aus?

Keine Ahnung. 10 oder 20cm sollten bei 10MHz kein Problem sein!?

Letzten Endes müssen die Daten ja aber auch wieder irgendwo abgeholt werden, womit wir dann wieder zum Thema Netto-Datenrate kommen, eben das, was an einem bestimmten Punkt im Programm ankommt, dass es auch verarbeitet werden kann.

Wo die zu verarbeitenden Daten von außerhalb diesen Systems eigentlich herkommen weiß ich (noch) nicht? Kann über UART, die laut Datenblatt auch SPI kann oder I2C oder ... oder.. USB? eingespeist werden.

Die Gesamtgeschwindigkeit, mit der das System die Daten über den RAM hin und her verarbeitet, ist wahrscheinlich nur grob abschätzbar. Da hab ich überhaupt keine Ahnung. Ist für mich das erste Mal, das ich an so etwas brüte.


Da unsere Aufbauten doch anscheinend etwas auseinander laufen, habe ich meinen (geplanten) mal versucht aufzuzeichnen.
Anklicken zum Vergößern
Die µCs holen sich vom Bus-Control die Erlaubnis die nach unten führenden Busleitungen zu den Schieberegistern und zum RAM zu benutzen. Die µCs, die keine Erlaubnis haben, müssen ihre Busleitungen auf Input schalten (hochohmig schalten).

Jeder µC hat drei SPI Leitungen (MOSI(serielle Adress Daten), SS und Clock) zu den Schieberegistern. Die Datenleitung ist zum zweiten Schieber in Reihe geschaltet.

Jeder µC hat einen 8 Bit breiten PORT über den RAM-Datenbus an den Daten I/Os des RAMs. Ob der RAM gelesen oder beschrieben werden soll wird bei meinem RAM über zwei/drei Leitungen /OE bzw /WE und eventuel CS (Output Enable, Write Enable, Chip Select) gesteuert.

Grober noch zu testender Ablauf:
µC holt sich Buserlaubnis.
µC schiebt Adressdaten über Schieberegister zum RAM
Bedient /OE und /WE (CS) des RAMs
legt oder entnimmt Daten über den RAM-Datenbus
µC gibt Bus beim Bus Controler wieder frei

[Moppi]

Dass man Bits einzeln übertragen kann, über zwei Leitungen ist mir auch klar. Das Prinzip ist ja auch dasselbe, wenn ich 8 Bit auf den Datenbus gebe und ein Signal sende, dass die Daten bereit stehen. Daraufhin bekomme ich eine Quittierung, ob sie abgeholt wurden. Man kann das auch stur nach Zeit machen, wenn man weiß in der Zeit schafft es die Gegenstelle die Daten abzuholen. Bis zu einer gewissen Taktrate, die hardwareabhängig ist, funktioniert das dann sogar. Aber hier ist es etwas anders. Ich muss jederzeit sichergehen, dass die Kommunikation einwandfrei verläuft. Weil ich hantiere ja hier mit mehreren Mikrokontrollern, die sich synchronisieren müssen.

Was ich mit Nettodatenrate meine ist: Die Daten kommen von egal woher. Aber um sie im Programm zu verwerten, muss man sie auch irgendwo abholen. Sie kommen zunächst in einem Puffer (SPI oder was anderes) an. Da muss ich prüfen, ist was im Puffer? - Ja, dann nimm das Byte raus und gib es zur Verarbeitung zum Programmcode zurück, der das Byte angefordert hat. Dieser Vorgang dauert ja auch Zeit, weil mit bestimmten Befehlen verbunden. Problem jetzt: ist die Schnittstelle schneller, als das Programm die Daten aus dem Puffer abholen kann, habe ich dort den Flaschenhals. Einerseits habe ich zwar eine enorme Übertragungsgeschwindigkeit, aber andererseits nur eine beschränkte Verarbeitungsgeschwindigkeit. Ich habe bspw. 8 Operationen inkl. Portzugriffe, je 8 Bit, Brutto, um zwei Byte Netto zu übertragen. Wenn mir das mit 125000Word/s gelingt, sind das theor. etwa 1MByte/s Brutto, die tatsächlich übertragen werden. Das ist auf jeden Fall schwierig zu ermitteln (weil bei der Ausführung der Software noch Unbekannte dabei sind - wie Unterbrechungen für Sachen die der Kontroller nebenbei noch tut: Interrupts, Zähler behandeln ..) und da muss man irgendwann mal das Endergebnis realistisch betrachten und nachmessen wie lange dann große Datenmengen zur Übertragung benötigen. Aber zum Abschätzen, auf was man da hinarbeitet - mit dem Konzept, finde ich es wichtig, dass man das ab und an reflektiert, was da überhaupt möglich ist oder wäre und wie man mit den Hindernissen umgeht.

Das Konzept mit der SPI-Schnittstelle ist auf jeden Fall bestens, wenn es darum geht, eine bekannte Menge Daten auszulagern und wiederzuholen. Ohne dass man die verfügbare Menge ext. Speicher überschreitet.

Ein Problem entsteht dann, wenn die Datenmengen unbekannt sind. Bzw. wenn die Datenmenge auf ein nicht vorher bestimmbares Maß anwachsen kann, wobei man sicher weiß, dass gewisse Größenordnungen (1GB) auch wieder nicht überschritten werden. In solchen Fällen ist immer gut, wenn man davon ausgehen darf, dass man "unbegrenzt" Speicher zur Verfügung hat. Zur Not eben durch Auslagerung. Das dauert zwar sehr viel länger, aber bringt nicht den Verarbeitungsprozess zum Erliegen.
Zurzeit kann ich noch gar nicht abschätzen, ob ich SPI sinnvoll einsetzen könnte. In der ersten Überlegung ja - könnte das Adressieren des Speichers vereinfachen. Ich kenne nur noch nicht alle Schwächen meines Konzepts, weil ich mit der Programmierung noch nicht fertig bin. Evtl. gibt es da auch gar keine. Ich habe einen Kontroller, der sich um den Speicher kümmert. Einen Weiteren, der die SD-Karte bedient. Drum herum habe ich D-Latches zur Abgrenzung zwischen dem Kontroller der Daten verarbeitet (Sender) und den anderen beiden (Empfänger), die sich um die Beschaffung etc. kümmern. Sender und Empfänger laufen in gewissen Grenzen asynchron und können das auch mit unterschiedlichen Geschwindigkeiten. Hat der Sender Daten zum Speichern abgegeben, dann nehmen die Empfänger das entgegen und der Sender macht sich auf den Weg, weitere Daten zu holen. Während dieser Zeit können die Empfänger die abgegebenen Daten verarbeiten (speichern). Beim Lesen dasselbe Prinzip in andere Richtung. Einige Verarbeitungszyklen laufen damit parallel, bei Sender und Empfänger und kosten damit keine zusätzliche Zeit. Vorgänge werden damit zeitlich verkürzt - so die Idee. Jede Datenverarbeitung kann man auch nur zu einem gewissen Teil parallelisieren, weil manche Vorgänge einfach nacheinander stattfinden müssen, weil voneinander abhängig.

MfG

[Searcher]

...

Das übersteigt meine Ambitionen dann doch etwas Inzwischen habe ich aber noch eine Teilaufgabe für mich entdeckt, die ich mir nochmal ansehen möchte. Die USART kann beim Mega88 (Mega328 ) auch als SPI Schnittstelle verwendet werden.

Da im Gegensatz zur SPI von double Buffer beim Transmitter geschrieben wird: Geht der schneller?
Kann man den parallel zur "normalen" SPI-Schnittstelle betreiben und hat man dann zwei SPI Schnittstelle mit schneller Übertragung zur Verfügung? Je schneller die Daten übertragen sind, desto mehr Zeit gibt es für andere Dinge.

Bin neugierig, wie es bei Dir weitergeht und vielleicht schreibst Du irgendwann mal, was es geworden ist oder was es mal werden sollte.

Gruß
Searcher

[Moppi]

Zurzeit brauche ich ewig für ein paar Codezeilen. Ich hab's gerade mal durchgezählt. Ohne RAM sind es 8 Steuersignale, mit denen die gesamte Beschaltungslogik koordiniert wird. Viele laufen immer über ein Byte, also einen Port. Vertue ich mich irgendwo mit einem Bit, kann es passieren, dass ich Ausgang auf Ausgang schalte oder Daten nicht rüberkommen, weil D-Latch-Ausgänge deaktiviert sind. Echte Gehirnakrobatik, zu jedem Zeitpunkt bei der Programmierung zu wissen, in welchem Zustand die Schaltung sich gerade befindet.

Na was es werden soll, ist Datenverarbeitung. Ich hatte schon geschrieben, dass ich mich von der Softwareebene (hier ist das vornehmlich Javascript und PHP) lösen möchte. Daten lesen, verarbeiten, Daten schreiben, Daten verändern (Stringoperationen allgemein, z.B.: indexOf, replace, split), Daten vergleichen. In Größenordnungen bis einige Megabyte. Um es kurz und knapp zu beschreiben: Assistenz in der Datenverarbeitung. Oder: softwarebasierte Assistenten.

Ich habe schon überlegt, ob es dann nicht sinnvoll ist ein extra Board zu bauen und hiermit eine Basis für die Integration mehrerer (vieler) Kontroller zu schaffen. Ich würde das vielleicht Borg Board nennen. Angelehnt an die bekannte Serie. So: erweitere einen bestehenden Verbund durch Assimilation weiterer Kontroller und/oder Speicher und mache ihn damit leistungsfähiger. - na ja, visionär

MfG

[Searcher]

Da im Gegensatz zur SPI von double Buffer beim Transmitter geschrieben wird: Geht der schneller?

Ich mußte mich doch noch an dem USART als SPI-Master im Mega88 versuchen.

Hab die ASM Initialisierungs- und Datensendebeispiele aus dem Datenblatt angepaßt und drei Bytes in 7,7µs, also knapp 400000 Bytes/s bei 8MHz Systemtakt abschicken können. Gemessen mit Oszi an dem, zusätzlich in die ASM-Routinen aufgenommenen SS Pin.

Auch der Master SPI-Takt am USART läßt sich auf halben Systemtakt einstellen indem man nur im Register UCSR0A das U2X0 Bit setzt. Der Geschwindigkeitsvorteil gegenüber der, ich nenn sie mal nativen HW SPI Schnittstelle kommt durch das "double buffering". Beim USART kann das Senderegister schon neu beschrieben werden während das vorhergehende byte noch rausgetaktet wird. Beim nativen SPI muß gewartet werden, bis das byte rausgetaktet wurde. Im Oszillogramm tauchen beim nativen SPI Pausen im Takt zwischen den gesendeten Bytes auf, die es beim USART nicht gibt.

Die Entgegennahme der Daten in den 74HC595 stellt kein Problem dar. Vermutlich eher die Bereitstellung der Daten aus der Anwendung heraus. Wenn man die native HW-SPI auch noch parallel betreibt dürfte das den Flaschenhals doch noch relativ enger machen

Gruß
Searcher