HIVE-Project

Das ist die einzige Kritische stelle.
Der rest sieht vernünftig aus.

Eventuell kommt noch eine kurze Rücknahme von CS während der Übertragung vor.
Hier würde der Chip das protokoll beenden und neu starten.

bei solchen befehlen z.B. outa[SIO3..SIO0] :=c >> 4 wird erst die 32 Bit Ausgangswert zurückgelesen dann bearbeitet und zurückgeschrieben.
Deshalb binn ich damals auf die Bitbefehle outa[CLK] :=0 gewechselt.

Ich binn mir ziemlich sicher das ich damit auch schon einmal Probleme hatte.

Was noch in Frage kommt ist dein FullDuplexSerialExtended probier mal einen Anderen.

PIC18F2550 hat geschrieben: ↑Do 25. Feb 2021, 10:21 CODE: ALLES AUSWÄHLEN
PUB ClockStrobe
' outa[CLK]~~
outa[CLK] :=1
' outa[CLK]~
outa[CLK] :=0

was ist jetzt genau das Problem?

Ich meine die Routine.

Mit den Werten komme ich besser klar als mit den komischen ~~~~~~ .

Wenn Du das mal in Pasm umgesetzt hast, wäre ich darann interessiert.
Was hast du für einen bezahlt.

Ich würde da aber zwei parallel zu 8 Bit verschalten.

Hast du einen Link zu dem Teil?

Chip kostet bei EXP-Tech 2,38€.
8Bit- Verschaltung ? Wie soll die aussehen? 2Chips gleichzeitig über SPI-Protokoll ansteuern stell ich mir nicht gerade simpel vor und welche Vorteile sollte das haben? 8Mbyte x8 Bit sollte doch reichen.
PASM-Umsetzung mach ich erst, wenn die Spin-Variante PIN-unabhängig funktioniert.
Mir ist immer noch nicht klar, was die Fehler produziert. Schaun wermal was mir noch einfällt.

Du machst aus 2x 4 Bit hintereinander Daten 8Bit Daten.
Bei zweien parallel entfällt das zusammenfügen.

Die Befehle und Adressen bleiben bei 4 Bit, werden aber auf die andere 4 Bit gespiegelt.

Durch die Einsparung an verwaltung und zusammenfügen/teilen kann man die Transferrate mehr als verdoppeln.

Das Speicherformat ändert sich von Byte auf Wort.

Fehler gefunden !?
Man lernt ja nie aus. Damit die ganze Sache funktioniert müssen beim Start alle 32 Port-Pins in der Datenrichtung gesetzt werden, wahrscheinlich um eine definierte Startkonfiguration zu erzeugen, dann funktionieren die Portregister auch wie gewünscht.
Nachdem ich (wie in der reg-ios.spin )
DB_IN = %00000000_00000000_00110000_00000000 'maske: dbus-eingabe (Beispiel für CLK und CS an 12 und 13) gesetzt habe, war alles gut.

Danach kann man die Ports manipulieren, wie man möchte (eigentlich logisch).

Jaaaa.... manchmal sieht man den Wald vor lauter Gemüse nicht.

So, jetzt mal sehen, wie ich den Speicherknirps im Hive unterbringe (Upgrade von 1MB nach 8MB )

PIC18F2550 hat geschrieben: ↑Do 25. Feb 2021, 19:06 Hast du einen Link zu dem Teil?

https://www.aliexpress.com/item/4000242457828.html ... ist evtl nichmal der aktuëll günsigste Anbieter. Die mehrwöchige spannende Warterei gibt's gratis obendrauf. Ist das nicht oberhübsch?

Ich schielte schon darauf, die als zusätzliche RAM-Disk an MicroPython-Käfern einzusetzen, aber kam bisher über's Buchmerkeln nicht hinaus.

Es ist in den Grundzügen geschafft, die Spin und PASM-Routinen sind funktionsfähig.
Für alle interessierten bitte hier schauen .. https://github.com/Zille9/PSRAM64H

zille9 hat geschrieben: ↑Mi 3. Mär 2021, 22:52 Es ist in den Grundzügen geschafft, die Spin und PASM-Routinen sind funktionsfähig.
Für alle interessierten bitte hier schauen .. https://github.com/Zille9/PSRAM64H

Super gemacht!

PSRAM64H/PSRAM_PASM.spin in Zeile 130 ist ein Fehler. Das if_z muss eine Zeile tiefer.

Sind nicht gleich?

Ist noch genug Platz im COGram um die Call CLOCKs mit zu ersetzen? Das bringt noch ein bisschen geschwindigkeit rein weil CALL und RET entfällt.

So genug gejammert.