RAM-Baustein

[Moppi]

@searcher

War eine gute Idee mit den 74HC161. Erst war ich skeptisch, mit der Reihenschaltung. Das funktioniert aber erstaunlicher Weise sehr gut. Schnell zählen die Dinger auch. Hatte bis jetzt noch keinen Zählfehler. Allerdings komme ich mit einem Atmega328 (16MHz Takt) auch nicht weit über 160KHz Taktfrequenz raus. Mitmachen soll der HC161 lt. Datenblatt 63MHz.

Busteilnehmer sollen auf der Request Leitung mit einem low anfordern und bekommen Zugriff vom Bus Controller mit einem low auf der Grant Leitung. Die Busteilnehmer sollen die Request Leitung so lange auf low halten bis sie den Bus wieder freigeben. Danach nimmt der Bus Controller das low von der Grant Leitung weg und kann den Bus dem nächsten Teilnehmer zuordnen.

richtig, war der einfachste Gedankengang

Die Requests sollen der Reihe ihres Eingangs nach behandelt werden. Gibt der erste den Bus frei, der zweite den Bus belegt und der dritte wartet, während der erste schon wieder anfordert, sollen Prioritäten vergeben werden bzw eine Warteschlange aufgebaut werden um den dritten vor dem ersten den Bus zuzuteilen.

Wenn ich das richtig verstehe, nimmst Du nur 2 Leitungen, an die Du alle Teilnehmer anschaltest? - Oder doch mehrere parallele? Sonst müsstest Du ja mit jedem Teilnehmer dieselbe Leitung abhören und dann müssen die raten, ob noch jemand anders gerne möchte oder ob sie zurzeit alleine am Bus horchen? Nicht, dass man Kollisionen nicht auflösen könnte. Einer wird der Erste sein, der zu irgendeinem Zeitpunkt sagt: ich belege die Leitung, vorher war sie frei.
Aber da gehst Du von einer anderen Seite ran, als ich. Da bin ich noch gar nicht.


MfG

[Searcher]

Wenn ich das richtig verstehe, nimmst Du nur 2 Leitungen, an die Du alle Teilnehmer anschaltest? - Oder doch mehrere parallele?

Nein, nein. Ich nehme parallele. Also von jedem Busteilnehmer zwei Leitungen (kein Bus) zum Buscontroller. Bei mir sind im Augenblick drei Busteilnehmer vorgesehen - also kommen von denen sechs Leitungen beim Buscontroller an. Die Fall c) Verdrahtung von der Arbiter Internetseite ohne Bus-busy Leitung. Die Busteilnehmer sind bei mir noch LEDs an denen ich die Zustände der Busleitungen betrachten kann. Ein, noch auf dem Steckbrett steckender Mega88 dient als Testmustererzeuger für die Requestleitungen. Die Muster schalte ich mit einem Taster weiter.

Wenn das Programm auf dem Buscontroller mal steht, versuche ich mit nur 74HC595 ohne 74HC161 weiterzumachen, da ich die Binärzähler nicht habe. Gleich geht es aber erst mal zum Radeln

Gruß
Searcher

[Moppi]

@searcher

Und schon weiter gekommen?

Schieberegister funktionieren auch als Zähler, bloß nicht in richtiger Reihenfolge der Zählerstände. Pro Takt kann man einen neuen, einmaligen Zählerstand erzeugen. Mit einem 8-Bit-Register sind das 256 Verschiedene. Eine gesamte 8-Bit-Adresse dort reinzuschieben dauert seine Zeit - wesentlich länger.

Ich bin noch bei der Steuerlogik. Die Hardware auf die Beine zu stellen, geht noch relativ flott. Dann muss aber die Softwaresteuerung zur Hardwarelogik passen. Gestern habe ich eine extra Steuerleitung eingeführt, um bessere Kontrolle über die Kommunikation zu haben. Eigentlich aus dem Grund, weil ich mir dachte, dass den Zähler rücksetzen und takten gemeinsam keine gute Idee wäre. Denn immerhin soll der Zähler bei Takt zählen, was aber direkt schon nach dem Rücksetzen passiert. Allerdings habe ich heute Morgen rausgefunden, dass der Zähler, wenn er während des Rücksetzens getaktet wird, nicht darauf reagiert. Also wenn das Rücksetzen aktiv ist und das Taktsignal auf LOW und beides zur selben Zeit umgeschaltet wird (Reset-Signal weg und Taktsignal auf HIGH). Ich meine auch gelesen zu haben dass der Zähler nur bei steigender Flanke zählt. Wenn die steigende Flanke vom Reset überlagert ist, zählt er wohl tatsächlich nicht.

Zurzeit bin ich doch erstaunt, welche Bruttodatenrate über die IO-Ports zu erreichen wäre. Bei der Adressierung habe ich z.Z. um die 125kByte/s netto. Allerdings ist das erst mal nur die Segmentadressierung. Einen Offset will ich später eigentlich auch noch einführen, dann sinkt die Nettodatenrate nochmal etwas. Dafür wird das Lesen und Schreiben schneller gehen; wenn nicht ständig die Adresse wahllos geändert wird. Dann werden wesentlich weniger Zyklen für Portoperationen benötigt. So dass ich damit rechne, in die Nähe der 200kByte/s netto zu kommen. Wenn ich über 160kByte/s käme, wäre ich fürs Erste auch zufrieden. Kommt die SD-Karte ins Spiel, sinkt die Datenrate nochmals, nach allem was ich probiert hatte auf max. 25kByte/s. Mal sehen. Bleibt noch spannend - vor allem aber kniffelig Hard-und Softwarelogik zusammen zu bekommen.

MfG

[Searcher]

Und schon weiter gekommen?

Ich bin kaum weiter

Ich hatte mich zu lange beim Buscontroller/Arbiter aufgehalten. Da gab es immer wieder Fälle, die nicht in meine Vorstellung paßten. zB brachte ein Controller, der eine BUsanforderung stellte und vor der Zuteilung wieder zurücknahm, die Reihenfolge der Übrigen durcheinander. Nachdem solche Bugs durch Flicken im Code entfernt waren, sah das Programm recht übel aus und muße nochmal neu geschrieben werden. Jetzt steht es aber, braucht jedoch, getaktet mit internem 8MHz Oszillator auf ATtiny44A, etwa 35µs von Entgegennahme der Anforderung bis Zuteilung des Busses, wenn natürlich kein anderer Controller den Bus belegt hat.

Dann hab ich die 74HC595 aufs Steckbrett gebracht und an den ersten Controller (ATMega88PA, 8MHz interner Oszillator) an die HW-SPI Schnittstelle angeschaltet. Deren Parallelausgänge sollen ja die Adresse am RAM setzen. Hier unterscheidet sich mein AUfbau schon von Deinem. Ich habe keine 74HC161 zur Verfügung (vielleicht besorg ich mir noch welche) Auch brauche ich für mein 32KiByte Speicher mit 15 Adressleitungen nur zwei 74HC595, die ich hintereinander geschaltet habe.

Nach Kampf mit den SPI Parametern wie CPOL und CPHA kommen die Bits richtig im Schieberegister an und der der SPI Takt läuft mit halbem Systemtakt also mit 4MHz. Ich benutze Bascom Befehle und brauche pro Adressbyte etwas mehr als 5µs zur Übertragung, also 10,2µs für eine 15(16)Bit Adresse. Gemessen mit Oszilloskop am Slave Select Pin, der auch von Bascom gesetzt wird. An der Stelle gibt es wahrscheinlich Optimierungsmöglichkeiten weil der SS sich nach Übertragung reichlich Zeit bis Rückkehr nach idle läßt. Erst soll aber der Rest noch funktionieren.

Heute möchte ich den Mega88 an den Buscontroller anschalten und anfangen die Busschnittstelle darauf zu programmieren. Der RAM Baustein ist noch tief in einer Schublade vergraben.

Ich meine auch gelesen zu haben dass der Zähler nur bei steigender Flanke zählt

Ja, "Table 3 Function table" im NXP Datenblatt bestätigt das - Mit /MR auf high!

Zurzeit bin ich doch erstaunt, welche Bruttodatenrate über die IO-Ports zu erreichen wäre. Bei der Adressierung habe ich z.Z. um die 125kByte/s netto.

Über HW-SPI und Schieberegister liege ich bei 200kByte/s mit 8MHz Controllertakt. Allerdings kann ich bei folgendem Datentransfer keine Zeit durch Adresserhöung mit einfachem Takt sparen. Und ich rechne noch nichts sondern lese einfach nur Bytes aus einem Array und schreibe sie per HW-SPI raus.

Bleibt noch spannend - vor allem aber kniffelig Hard-und Softwarelogik zusammen zu bekommen.

Das gefällt mir auch.

Gruß
Searcher

PS Auf die Sache mit den Schieberegistern als Zähler komme ich später vielleicht noch mal zurück.

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