ZX81-Kompatibler aus Standardbauteilen: ZX81NU

[Jens]

Hallo Jungs!

Ich steig da nicht durch und weiß gar nicht, wovon Ihr genau redet (irgendwas mit SD).

Aber meine Frage: kann ich irgendwie mitstreiten??

Gruß
Jens

[siggi]

Wo steht in der Doku der SD-Platine, daß /CS HIGH sein muß?

Meinst Du ich habe diesen Screenshot hier aus Spaß gepostet, weil mir langweilig ist ?
http://forum.tlienhard.com/phpBB3/viewt ... 300#p25656

Da steht "sowie" in Bezug auf CS und Activate. Sowie heißt nach meinem Sprachschatz soviel wie UND. Also gehören nach der Beschreibung für mich beide Signale auf +5V oder eben schaltbar wenn man das möchte. Entweder ist dieser Satz falsch oder der Verfasser hat sich sehr ungeschickt ausgedrückt.

Moin Karl
um diesen Satz falsch zu verstehen, muß man ihn schon aus dem Kontext reissen, wie es Dein Screenshot tut. Hier ist der ganze Abschnitt (der leider auf 2 Seiten verteilt ist):

Minimale_IO.jpg (153.93 KiB) 4776 mal betrachtet

Das "sowie" bezieht sich auf die Auflistung der minimal benötigten Signale:

Code: Alles auswählen

3 V
5 V
Masse
Clock
Datenausgang
Dateneingang
CS Signal
[color=#FF0000]SOWIE/UND[/color]
Activate Leitung

Und für diese Signale sind gleich Hinweise zum Anschluß gegeben: z. B.
bei 3V: "(wenn sich kein Spannungsregler aus dem P001 Modul befindet)"
bei CS Signal: "z. B. B0 wie in unserem Softwarebeispiel"
und bei Activate Leitung: "an einem beliebigen Port bzw. sonst direkt an 5V für permanente Aktvität"

Nur auf "Activate Leitung" bezieht sich der Anschluß an 5V. Wäre ja auch blöd, wenn man auch CS an +5V hängen würde, weil man dann die SD-Karte nie aktivieren/deaktivieren kann, was man aber während der Initialisierung tun MUSS (Clocks bei CS=HIGH, Kommandos bei CS=LOW)! Also kann sich der Satzteil "an einem beliebigen Port bzw. sonst direkt an 5V für permanente Aktvität" nie und nimmer auf CS beziehen!

Zudem ist im ganzen Datenblatt immer nur vom "Pegelwandler" die Rede, von der Invertierung irgend eines Signals findet man da nichts!

Explizit werden an anderer Stelle CS und Activate Leitung getrennt beschrieben. Und nur bei Activate Leitung werden die +5V genannt und bei CS wird sich immer nur auf die SD-Karte bezogen (und somit implizit deren Pegel):

CSvsActivate.jpg (281.17 KiB) 4776 mal betrachtet

Und hier nur zu Activate Signal:

Activate.jpg (153.26 KiB) 4776 mal betrachtet

Nach dieser Beschreibung betreibe ich die SD-Karte seit Jahren im Laptop.

Dann verstehe ich ehrlich gesagt nicht, warum es a) jetzt bei Dir nicht läuft

Ich auch nicht ...

und Du b) hier nach Unterstützung fragst.

da es "hier" auch noch andere User mit SD/SPI/Pegelwandler-KnoffHoff gibt (Bodo, Joachim, Tom, Olli, Jens, ...) , die andere Hardware zur Pegelanpassung benutzen und die deshalb gut als "Vergleichsojekt" dienen kann, um Fehler in meiner Pegelanpassung aufzudecken.
Aber leider ist bisher kein unterschiedliches Verhalten bei unterschiedlichen Pegelwandlern erkennbar.

Gruß
Siggi

[PokeMon]

Moin Karl
um diesen Satz falsch zu verstehen, muß man ihn schon aus dem Kontext reissen, wie es Dein Screenshot tut. Hier ist der ganze Abschnitt (der leider auf 2 Seiten verteilt ist):

siggi,
ich habe noch nie so ein schlechtes, weil interpretationsfreudiges "Datenblatt" zu einem Produkt gesehen, insofern ist es schwierig hier etwas aus dem m.E. nicht vorhandenen Kontext zu reissen. An keiner (!) Stelle im gesamten Datenblatt steht etwas zur exakten Polarität des CS Signals, was im Übrigen als CS und nicht als /CS bezeichnet wird. Ansonsten wird von einem aktiven CS geredet. Dass ein CS nur low aktiv sein kann oder muss entspricht nicht unbedingt der Realität.

Ich steuere gerade auch andere SPI Bausteine an wie den RTC Chip auf dem ZXblast und der verlangt ein high Signal um den Baustein zu aktivieren (DS1302). Ein anderer Baustein AT25SF041 (4 Mbit SPI Flash ROM) arbeitet wieder mit einem low aktiven Select Signal. Insofern ist das für mich niemals zwangsläufig und ich würde hier im Zweifel einfach nachmessen, was auf der SD Karte ankommt wenn Du schon mit dem Oszilloskop arbeitest. Erfahrungsgemäß sind solche hartnäckigen Probleme meistens auf sehr einfache Ursachen zurückzuführen, auf die der Proband aber oft nicht kommt, weil er sich felsenfest sicher ist, dass alles so ist wie er meint.

Und ansonsten sagt der Screenshot von mir mit dem einzigen Satz, den ich aus dem Zusammenhang gerissen habe aber zugleich auch der einzige Satz ist, der für einen Ausstehenden irgendwas über die exakte Polarität des CS Signals aussagt: Beide Signale müssen nach meinem Verständnis high sein und man kann sie auch gemeinsam an einem Port Ausgang eines Mikrocontrollers legen und bei Bedarf einschalten. Da hier nur die AUSGANGS(!) Treiber eingeschaltet werden, verhindert das m.E. auch nicht, dass das CLK Signal an die SD Karte durchkommt wenn die Karte nicht selektiert ist, weil das ja letztlich ein Eingang ist und kein Ausgang.

Möglicherweise haben sie das CS Signal sogar absichtlich invertiert, damit man es eben zusammen mit CS auf einen Port Pin schalten kann und sozusagen im Zweifel einen Pin weniger braucht. Als Konsequenz hätte man dann wieder auf den Activate Pin verzichten können (der aus meiner Sicht sowieso eher obsolet ist) - aber woher soll ich wissen, was die Entwickler bei der Konzeption geritten hat. Da sonst nirgendwo im Datenblatt davon die Rede ist WANN das CS Signal aktiv ist (high oder low) und man eigentlich zu Rätselraten gezwungen ist, würde ich der Einfachheit halber direkt auf der Karte kontrollieren. Mit dem Oszi, dauert wenige Minuten und dann hat man das Thema empirisch gelöst und nicht intellektuell.

Hast Du denn mal den "Rest" vom Datenblatt angefordert wie Schaltplan, Oszilloskopbilder und Softwaretipps, die der Hersteller des Moduls nicht veröffentlichen will und die nur den Erwerbern des Moduls zur Verfügung steht ? Könnte auch hilfreich sein. Mir ist bei den SD Karten überhaupt das Konzept schleierhaft, wieso sie bei nicht aktivierter Karte (CS Signal inaktiv) die CLK Leitung auswerten. Das ist eine logische Durchbrechung des CS Signals, denn wenn das nicht aktiv ist, sollte ein angeschlossener Baustein auch nicht darauf reagieren. Das ist wiederum eine Baustelle der SD Group, ich finde es nur konzeptionell fragwürdig gelöst, auf diesem Wege zwischen 1 Bit und 4 Bit Schnittstelle umzuschalten. Wenn ich also wirklich einen SPI Bus habe, ist das kontraproduktiv wenn die Karte hier automatisch umschaltet nur weil sie an einem gemeinsamen CLK hängt mit einem anderen Baustein.

Weitere Ideen habe ich jetzt sonst leider auch nicht. Dass es an der Pegelwandlung liegt, halte ich für eher unwahrscheinlich. Und auch das kann man ja innerhalb weniger Minuten mit dem Oszi nachmessen und ausschließen.

[ZX-Heinz]

Also, ich lese die Sätze
CS - Solange aktiv, geht die Karte auf Empfang für Daten/Befehle
Activate - 5 V an diesem Anschluss ...
so:
CS=H für Empfang, also Pins auf Input. (Activate-Signal ist egal). CLK und alles weitere wird ausgewertet.
CS=L (und natürlich Activate=+5V) für Senden.

Ich habe bisher mit dem VDRIVE am Speccy (Selbstbau-IO-port) nie Probleme gehabt, weder im UART- noch im SPI-Modus. Am ZXNU hängt es an der vorbereiteten SPI-Schnittstelle und läuft ebenso problemlos.

Um welchen Modul handelt es sich denn, mit dem es die Probleme gibt? Ebenso wie Jens kann ich der Diskussion nicht ganz folgen. Vielleicht kann ich ihn einmal bei mir dranhängen (Speccy oder Zeddy)

[PokeMon]

Also das hat m.E. jetzt nicht mit dem VDRIVE zu tun, das ist eine andere Hardware und erfordert auch andere Treiber.
Das Problem ist ab hier näher beschrieben:

http://forum.tlienhard.com/phpBB3/viewt ... 275#p25581

[PokeMon]

CS=H für Empfang, also Pins auf Input. (Activate-Signal ist egal). CLK und alles weitere wird ausgewertet.
CS=L (und natürlich Activate=+5V) für Senden.

Kann man mal sehen, noch eine andere/weitere Interpretation desselben Datenblattes.

[ZX-Heinz]

Also das hat m.E. jetzt nicht mit dem VDRIVE zu tun, das ist eine andere Hardware und erfordert auch andere Treiber.
Das Problem ist ab hier näher beschrieben:

http://forum.tlienhard.com/phpBB3/viewt ... 275#p25581

Hallo Pokemon,
danke für den Link. Dann kann ich nicht helfen, ich habe weder besagtes SD-Platinchen, noch MEFISDOS.

[siggi]

Wie auch immer die Datenblätter des SD-Platinchens (falsch) interpretiert werden können: das sagt Graf OSZI während
"D D:/":
Unten: Channel 2 mit 2 V/cm: PIN 8 des SD-Platinchens (mit nMemCS = PIN8 SD-Platinchen)
Oben: Channel 1 mit 2 V/cm: Pin 1 der SD-Karte CS)

CS.jpg (236.2 KiB) 4716 mal betrachtet

Also von Invertierung zwischen Eingang und Ausgang des SD-Platinchens sehe ich da weit und breit nix, nur die Pegelumhebung auf +3V.

Und hier bin ich im Einzelschritt mit ASDIS durch die TXD-Routine durchgegangen:
Oben: CS an der SD-Karte
Unten: Clock an Pin 7 des SD-Platinchens:

CLOCK-TXD.jpg (235.93 KiB) 4716 mal betrachtet

Während die Daten zur Karte geschoben werden, ist CS an der Karte LOW (oben), so wie es auch in den Datenblättern der SD-Karte (siehe weiter oben) gefordert wird.

Und hier die habe ich die Daten (oben: Pin 2 der SD-Karte während TXD) überprüft: $AA bringt Pin 2 zum Wackeln, unten ist das Clock-Signal an der SD-Platine (PIN 7):

CLOCK-DATA.jpg (231 KiB) 4716 mal betrachtet

Sieht also alles normal und nach Datenblatt (wie ich es verstehe) aus ...

Siggi

[siggi]

Habe mir heute nochmal die Signale an SD-Platinchen und SD-Karte angesehen (CLOCK, CS, Data-IN): sie werden alle nicht-invertiert an die SD-Karte mit 3V-Pegeln weitergereicht.

Und dann habe ich mir Clock und Data-IN am Eingang des SD-Platinchen und an der SD-Karte angesehen (bin dazu in ASDIS im Einzelschritt durch TXD durchgegangen und habe $AA gesendet):

Eingang SD-Platinchen mit 5V: oben Data-IN, unten Clock:

DIN-CLK-5V.jpg (116.8 KiB) 4702 mal betrachtet

Man sieht, daß Ollis Sparinterface die Daten bei fallender Clock übernimmt.

Und hier Data-IN direkt an der SD-Karte (unten Clock am SD-Platinchen):

DIN-CLK-3V-HIGH.jpg (147.18 KiB) 4702 mal betrachtet

DIN-CLK-3V-LOW.jpg (146.65 KiB) 4702 mal betrachtet

An der SD-Karte kommt also alles an, was an Signalen so notwendig ist (und in der richtigen Polarität). Aber die SD-Karte antworted dennoch nicht

Siggi

[PokeMon]

Gut, dass war es ja immerhin wert aus meiner Sicht zu überprüfen.
Wenn Du also nun sichergestellt hast, was an der Karte ankommen soll und das ankommt, dann gibt es aus meiner Sicht nur folgende Möglichkeiten:

* Datenfehler (MSB/LSB vertauscht, falsche Routine angesprochen)
* Hardwaredefekt (SD Karte oder Kartenleser)
* Initialisierungsproblem

Letzteres könnte man vielleicht umgehen, indem man die SD Karte erst einsteckt, wenn Dein Programm läuft. Möglicherweise gibt der NU beim Startup aus seinem ROM irgendwelche Sequenzen auf den SPI Leitungen aus (Initialisierung des Flash Bausteins) die Deine SD Karte nicht mag und zum Absturz oder zumindest zum Schweigen bringt. Reset Anschluss haben die Dinger ja auch nicht. Ich würde mal die Karte ziehen und nur kurz vor Deinem Test frisch einstecken.

[siggi]

* Datenfehler (MSB/LSB vertauscht, falsche Routine angesprochen)

Das ist unwahrscheinlich, da ich ja von funktionsfähigen Routinen für PIO ausgegangen bin und "nur" den SPI-Zugriff angepaßt habe.
Hier was zur Reihenfolge der Sendens der Bits:

Command-MSB.jpg (87.33 KiB) 4690 mal betrachtet

MSB soll zuerst gesendet werden. M.E. ist dies durch die RXD/TXD-Routine gegeben.

* Hardwaredefekt (SD Karte oder Kartenleser)

Die Karte selbst funzt am PIO-Interface eines anderen Zeddy. Und Joachim hatte ja mit anderem Pegelwandlerplatinchen auch keinen Erfolg. Wenn meines defekt ist, dann sollte es anderwo ja klappen ...

* Initialisierungsproblem
Letzteres könnte man vielleicht umgehen, indem man die SD Karte erst einsteckt, wenn Dein Programm läuft.
Möglicherweise gibt der NU beim Startup aus seinem ROM irgendwelche Sequenzen auf den SPI Leitungen aus (Initialisierung des Flash Bausteins) die Deine SD Karte nicht mag und zum Absturz oder zumindest zum Schweigen bringt. Reset Anschluss haben die Dinger ja auch nicht. Ich würde mal die Karte ziehen und nur kurz vor Deinem Test frisch einstecken.

Habe ich probiert: Mefisdos gestartet, VDRIVE abgeklemmt, Karte gesteckt: gleicher Effekt bei "D D:/": Plattenfehler

[PokeMon]

Dann sind aber nicht mehr viele Fehlerquellen denkbar.
Wenn dieselbe Karte im anderen Modul funktioniert und die gleichen Daten kommen ...

Auch auf die Gefahr hin, dass Du mich gleich steinigst:
Die 3.3V Spannung liegen schon an der SD Karte (Betriebsspannung) ?
Weil das Modul gibt es ganz offenbar mit und ohne 3.3V Regler und hat noch einen 3.3V Eingang am Steckverbinder.

[siggi]

Dann sind aber nicht mehr viele Fehlerquellen denkbar.
Wenn dieselbe Karte im anderen Modul funktioniert und die gleichen Daten kommen ...

Das ist ja da Problem

Auch auf die Gefahr hin, dass Du mich gleich steinigst:
Die 3.3V Spannung liegen schon an der SD Karte (Betriebsspannung) ?
Weil das Modul gibt es ganz offenbar mit und ohne 3.3V Regler und hat noch einen 3.3V Eingang am Steckverbinder.

Auch die 3,ebbes V sind da. Und laut Oszi eisern. Hatte schon vermutet, daß ich der 'nen C spendieren müßte (Kabellänge ca. 15 cm), aber da tut sich nix beim Schreiben (kein Einbruch, kein Überschwinger)



Siggi

PS: Sack Zement, wieso klappt das nicht? Als ich mein schnelles MMC-Interface entwickelt habe, habe ich den PIO-Treiber angepaßt und das lief auf Anhieb (*) ....

* bei meinem Zeddy

[PokeMon]

Ja, so langsam gehen mir die Ideen aus.
Vielleicht noch ein Timing Problem ?
CLK Polarität, also Ruhe-Level low ?

Ich habe da noch was gefunden zur Initialisierung, da reichen die 74 CLKs nicht aus (das soll offenbar ein Reset Kommando sein resp. kann man so einen Reset ausführen). Vor CMD0 soll noch CD/DAT3 auf low gezogen werden, um SPI auszuwählen (sonst SD Interface aktiv).

1) Supply Voltage for initialization.
Host System can apply the Operating Voltage from initialization to the card.
Apply more than 74 cycles of Dummy-clock to the SD card.

2) Select operation mode (SD mode or SPI mode)
In case of SPI mode operation, host should drive 1 pin (CD/DAT3) of SD Card I/F to “Low” level.
In case of SD mode operation, host should drive or detect 1 pin of SD Card I/F (Pull up register of 1 pin is pull
up to “High” normally).
Card maintain selected operation mode except re-issue of CMD0 or power on below is SD mode initialization procedure.

3) Send the ACMD41 with Arg = 0 and identify the operating voltage range of the Card.

Hier gefunden, Toshiba Datenblatt, wird aber für andere SD Cards genauso gelten, denke ich:

http://www.mikrocontroller.net/attachme ... 08G7B7.pdf

[PokeMon]

Nochmal eine andere Frage, wie ist denn genau Deine Initialisierungssequenz (nach den 74 Takten) ?

Verwendest Du CMD8 ?
Gibt CMD0 überhaupt Daten zurück ?

Ich habe in der Spezifikation folgende Initialisierung entdeckt, die CMD8 wohl zwingend erfordert, um der SD Karte die angeschlossene Betriebsspannung mitzuteilen und diese daraufhin entscheiden zu lassen, ob sie für diese Spannung überhaupt funktioniert. So habe ich das verstanden auf die Schnelle. CMD8 habe ich jetzt im Source nicht entdeckt.

7.2.1 Mode Selection and Initialization
The SD Card is powered up in the SD mode. It will enter SPI mode if the CS signal is asserted (negative) during the reception of the reset command (CMD0). If the card recognizes that the SD mode is required it will not respond to the command and remain in the SD mode. If SPI mode is required, the card will switch to SPI and respond with the SPI mode R1 response.
The only way to return to the SD mode is by entering the power cycle. In SPI mode, the SD Card protocol state machine in SD mode is not observed. All the SD Card commands supported in SPI mode are always available.
Figure 7-2 shows the initialization sequence of SPI mode.
SEND_IF_COND (CMD8) is used to verify SD Memory Card interface operating condition. The argument format of CMD8 is the same as defined in SD mode and the response format of CMD8 is defined in Section 7.3.2.6. The card checks the validity of operating condition by analyzing the argument of CMD8 and the host checks the validity by analyzing the response of CMD8. The supplied voltage is indicated by VHS filed in the argument. The card assumes the voltage specified in VHS as the current supplied voltage. Only 1-bit of VHS shall be set to 1 at any given time. Check pattern is used for the host to check validity of communication between the host and the card.
If the card indicates an illegal command, the card is legacy and does not support CMD8. If the card supports CMD8 and can operate on the supplied voltage, the response echoes back the supply voltage and the check pattern that were set in the command argument.
If VCA in the response is set to 0, the card cannot operate on the supplied voltage. If check pattern is not matched, CMD8 communication is not valid. In this case, it is recommended to retry CMD8 sequence.

http://users.ece.utexas.edu/~valvano/EE ... r_Spec.pdf

Bildschirmfoto 2016-08-30 um 21.38.16.png (235.49 KiB) 4668 mal betrachtet

[PokeMon]

Noch ein Hinweis, in der Spezifikation steht außerdem, dass die SD Karte nach einem Reset Zustand (oder Power On) nur folgende Kommandos akzeptiert:

Code: Alles auswählen

CMD8
ACMD41
CMD58
CMD59

Wenn Du ein anderes Kommando sendest, ist es möglich, dass Du gar keine Antwort bekommst. Möglicherweise nicht mal ein Invalid Command (keine R1 Antwort). CMD8 ist glaube ich schon ein wichtiges Kommando.

7.2.7 Reset Sequence
The SD Memory Card requires a defined reset sequence. The card enters an idle state after power on reset or reset command (CMD0 for SD memory card). In this state, the only valid host commands are CMD8 (SEND_IF_COND), ACMD41 (SD_SEND_OP_COND), CMD58 (READ_OCR) and CMD59 (CRC_ON_OFF).
For the Thick (2.1 mm) SD Memory Card - CMD1 (SEND_OP_COND) is also valid - this means that in SPI mode, CMD1 and ACMD41 have the same behaviors, but the usage of ACMD41 is preferable since it allows easy distinction between an SD Memory Card and a MultiMediaCard. For the Thin (1.4 mm) Standard Size SD Memory Card, CMD1 (SEND_OP_COND) is an illegal command during the initialization that is done after power on. After Power On, once the card has accepted valid ACMD41, it will be able to also accept CMD1 even if used after re-initializing (CMD0) the card. It was defined in such way in order to be able to distinguish between a Thin SD Memory Card and a MultiMediaCard (that supports CMD1 as well).

Ob CMD1 erlaubt ist, hängt offenbar auch noch vom Kartentyp ab.
Welche Karte verwendest Du denn ? SD oder MMC ? Welche Größe ?

Auf den ersten Blick sehe ich hier Parallelen zwischen SD Card und USB Interface - weniger funktional als mehr der Umfang der Dokumentation und der Zeitaufwand für wirklich tiefen Einstieg (wenn's eben nicht ganz rund läuft).

[siggi]

Ja, so langsam gehen mir die Ideen aus.
Vielleicht noch ein Timing Problem ?
CLK Polarität, also Ruhe-Level low ?

Ich habe da noch was gefunden zur Initialisierung, da reichen die 74 CLKs nicht aus (das soll offenbar ein Reset Kommando sein resp. kann man so einen Reset ausführen). Vor CMD0 soll noch CD/DAT3 auf low gezogen werden, um SPI auszuwählen (sonst SD Interface aktiv).

1) Supply Voltage for initialization.
Host System can apply the Operating Voltage from initialization to the card.
Apply more than 74 cycles of Dummy-clock to the SD card.

2) Select operation mode (SD mode or SPI mode)
In case of SPI mode operation, host should drive 1 pin (CD/DAT3) of SD Card I/F to “Low” level.
In case of SD mode operation, host should drive or detect 1 pin of SD Card I/F (Pull up register of 1 pin is pull
up to “High” normally).
Card maintain selected operation mode except re-issue of CMD0 or power on below is SD mode initialization procedure.

3) Send the ACMD41 with Arg = 0 and identify the operating voltage range of the Card.

Hier gefunden, Toshiba Datenblatt, wird aber für andere SD Cards genauso gelten, denke ich:

http://www.mikrocontroller.net/attachme ... 08G7B7.pdf

Hi Karl
auf so hoher Ebene hat sich zuletzt Bodo Gedanken gemacht. Und die Karte kriegt ja 80 Dummy-Clock ...

Nicht vergessen: auf PIO-Interface werden die gleichen High-Level-Kommandos benutzt, wie beim NU. Und die Kommandos funktionieren ja auf PIO-Interface. Ich drehe ja nur auf Bit-Level an der Schnittstelle ...

Tatsächlich benutze ich eine 32 MB-MMC-Karte. Aber die kriegt die gleichen Kommandos wie auf PIO-Interface, wo es ja klappt....

Wenn Flanke, MSB/LSB, Polarität passt: ist da vielleicht irgendwo ein Clock zu viel, der alles aus dem Takt bringt? ????????
Ruhe-Pegel der Clock muß ich noch checken ...

Gruß
Siggi

[PokeMon]

Hi siggi,

noch ein letzter Hinweis dazu von mir (bin dann jetzt mal längere Zeit offline).

Die benutzten Code Sequenzen scheinen nicht unproblematisch zu sein. Möglicherweise gibt es hier Abhängigkeiten vom Kartenleser und Kartentyp/Hersteller/Herstellungsdatum/Kapazität. Wenn ich nochmal den Code ansehe, scheint CMD1 ein "reserved command" zu sein, was nicht von jeder Karte unterstützt wird. Weiterhin sehe ich in dem Treibercode, dass direkt nach dem Senden des CMD0 nochmal ein $FF gesendet wird und erst danach in die Leseroutine gesprungen wird, die auch lauter $FF sendet und gleichzeitig löst. Der Sinn dieses extra Senden von $FF ist unklar weil die Leseroutine das auch macht und eventuelle Latenzzeiten bei den Antworten automatisch ausgleicht.

Das Problem kann aber sein, dass die Karte sehr schnell (sofort) auf CMD0 antwortet, weil es ein sehr einfaches Reset Kommando ist und die Antwort dann gar nicht mitbekommen wird. CMD1 kann wiederum dazu führen, dass die Karte gar nicht mehr antwortet. Die Empfehlung lautet CMD8 zu verwenden, was wohl erst später eingeführt wurde und CMD1 nur zu nutzen, wenn die Karte CMD8 nicht kennt. Hier haben wir dann ein Kartenabhängigkeit. In der Spezifikation steht bei SD Karten, CMD1 wäre "reserved".

Warum es dennoch an dem anderen Kartenleser funktioniert, kann wiederum mit dem Kartenlesertyp zu tun haben. Ich vermute mal, Du hast nicht den gleichen Lesertyp jetzt am NU wie den Leser, der läuft.

Hier ist eine recht detaillierte Antwort zu Initialisierungsprozeduren:
http://electronics.stackexchange.com/qu ... ion-in-spi

Some controllers (newer and higher capacity cards mostly) will simply stay in IDLE if you issue CMD1 to them. You should first issue CMD8 0x1AA after the reset (CMD0), and then try to use CMD55 + ACMD41. If and only if that fails, use CMD1.

actually, many SD cards (mostly newer ones, my Sony SR-32C4 32GB being one) won't start at all without CMD8 issued beforehand. Also, the clock is usually not an issue, as long as it's within sensible range. – vaxquis Jun 4 at 22:39

Vielleicht kann Bodo was dazu sagen, wenn er den Code damals geschrieben hat.

[siggi]

Hi Karl
die aktuellen Kommandos und deren Timing läuft ja auf dem PIO-Interface ohne Probleme. Also sehe ich da erstmal keinen Änderungsbedarf (außer irgendwelche neuen SD-Karten werden nicht initialisiert).

Es ist auch nicht so, daß die Karte zu schnell oder zu langsam antwortet: sie antwortet garnicht (habe jedenfalls deren Datenausgang noch nie wackeln sehen).
Also scheint sie die Kommandos nicht zu erkennen/verstehen.

Wesentliche Timing-Änderung zum PIO-Interface ist hier: Clock-Pulse sind kürzer. Aber m. E. im gültigen Bereich.

Gruß
Siggi

PS: zu "Warum es dennoch an dem anderen Kartenleser funktioniert, kann wiederum mit dem Kartenlesertyp zu tun haben. Ich vermute mal, Du hast nicht den gleichen Lesertyp jetzt am NU wie den Leser, der läuft."

Leider läuft mein Laptop mit gleicher SD-Platine derzeit nicht. Aber Karten, die darin gelesen/geschrieben wurden, werden auf NU (mit gleichem SD-Platinchen) nicht erkannt

[siggi]

Gibt's eigentlich einen neueren/korrigierten Schaltplan des NU als den auf Seite 1 dieses Threads?

Ich vermisse darin z. B. den Anschuß der "Mini-LED-Anzeige".

Gruß
Siggi

[PokeMon]

Es ist auch nicht so, daß die Karte zu schnell oder zu langsam antwortet: sie antwortet garnicht (habe jedenfalls deren Datenausgang noch nie wackeln sehen).
Also scheint sie die Kommandos nicht zu erkennen/verstehen.

Du kannst ja den Kartenleser ja mal testweise an Deine PIO anschließen.

Meiner Meinung nach hat die Implementierung der Leseroutine aber auch noch eine weitere Schwachstelle (neben dem Verwerfen des ersten Bytes direkt nach dem Schreiben).
Nach der SD Card Spezifikation antwortet die SD Karte auf Befehle nach "einigen" Taktzyklen, erkennbar an einem Low Bit. Antworten fangen immer mit einem Low Bit an, bleibt es high, "rechnet" die Karte noch. Jetzt liest aber die Routine RXD einfach stur immer ganze Bytes - demzufolge funktioniert die Leseroutine nur wenn die Antworten immer in 8 Bit Zyklen kommen. Rein theoretisch kann die SD Karte aber auch nach 5, 13 oder 28 Takten antworten. Ich konnte dem Standard nicht entnehmen, dass die Karte explizit nach 8, 16 oder 24 Takten antwortet.

Jetzt ist aber wenn ich es richtig verstanden habe, aber sowieso der Treiber im NU über "seriell" (driver.txt) nicht identisch mit dem PIO Driver. Insofern weiß ich auch gar nicht, ob sich das generell vergleichen läßt wenn die SD Karte an der PIO (mit anderer Software) läuft im Vergleich zum NU (anderer Treiber). Möglicherweise funktioniert der Treiber in dieser Form auch nur mit dem Microdrive (SPI Flash ROM auf dem NU).

[siggi]

Jetzt ist aber wenn ich es richtig verstanden habe, aber sowieso der Treiber im NU über "seriell" (driver.txt) nicht identisch mit dem PIO Driver.

Doch, auf Byte/Command-Level sind beide Treiber identisch, nur werden bei der PIO die Bits seriell und mit in Software generierten Clock über einen PIO-Port ausgegeben/eingelesen und beim NU seriell mit hardwaregenerierter Clock über das Sparinterface.

Insofern weiß ich auch gar nicht, ob sich das generell vergleichen läßt wenn die SD Karte an der PIO (mit anderer Software) läuft im Vergleich zum NU (anderer Treiber). Möglicherweise funktioniert der Treiber in dieser Form auch nur mit dem Microdrive (SPI Flash ROM auf dem NU).

Aber ich weiß es
Denn auch das schnelle MMC-Interface mit PIPO, das ich mal gebastelt hatte, benutzt die gleichen Routinen wie im PIO-Treiber, nur das Wandeln in serielle Bits wird vom PIPO (in Hardware) übernommen und die Clock wird von der Zeddy-Clock abgeleitet.
Nur auf Bit-Ebene unterscheiden sich die Treiber für PIO, PIPO und NU, nicht auf Byte bzw. Kommandoebene. Und natürlich im Timing ...

Gruß
Siggi

[siggi]

So, hier nochmal das ASDIS-Listing des PIO-Treibers: die Kommandos an die MMC sind identisch, nur die Bitbangerei ist anders (die betroffenen/geänderten Routinen hatte ich ja weiter oben schon genannt):

PIO-DRIVER.txt

(20.93 KiB) 60-mal heruntergeladen

Damit man die RXD/TXD-Routinen besser versteht: hier ein Link zu Hardware:
http://forum.tlienhard.com/phpBB3/viewt ... ptop#p1661

Mir ist da noch ein Timing-Unterschied zwischen PIO- und NU-Interface aufgefallen (TXD-Routine). Wenn es daran liegt, dann haben wir erstmal verloren, denn das Timing des NU ist in Hardware gegossen:
- beim PIO-Interface wird fallende MMC-Clock, /CS und Data-Out GLEICHZEITIG am PIO-Port rausgetrommelt
- beim NU wird erst fallende MMC-Clock und nach Gatterlaufzeit am Inverter und Latch danach erst /CS und Data-Out ausgegeben. /CS wir also erst NACH der fallenden Flanke der MMC-Clock aktiv.

Ich gucke mal, ob das eine kleinen, aber feinen Unterschied macht. Da ich aber demnächst in Urlaub und Kur in zeddyfreien Zonen weilen werde, könnte das noch etwas dauern ...

Gruß
Siggi

[Paul]

So, da in Nordhorn gestern und heute nochmal einige Platinen verkauft wurden und wir feststellen mussten das Reichelt den 74HCT4075 nicht mehr führt habe ich 30 Stück bestellt. Interressenten können sie dann bei mir bekommen.
Liebe Grüße
Paul

[Joachim]

Hallo Paul,
nachdem ich ja noch eine Platine habe und zur Sicherheit, würde ich gerne zwei ICs bestellen. Eilt nicht.
Vielen Dank!