Hallo Besucher, der Thread wurde 2,7k mal aufgerufen und enthält 28 Antworten

letzter Beitrag von StefR am

SD2IEC Larsp & 16GB Karte

  • Moinmoin,


    vor einiger Zeit habe ich mir das SD2IEC auf Basis des Larsp-Designs um einen 1284P aufgebaut und im Rechner verwurstelt. Bis zu dem Zeitpunkt, als meine olle 1GB-SD-Karte den Geist aufgab, hat das ganze auch prächtig funktioniert.


    Nun, das ganze lag jetzt ein paar Monate auf der Seite, eine 16GB Sandisk-Karte kam in den Zeitraum hinzu, aber leider kann mein C64 mit der Karte nichts anfangen; ich lande immer auf dem EEPROM-FS. Auch 'Load "$=P",8 ' zeigt mir keine Karte an. Vorbereitende Maßnahmen wie Fat32 und Co ist so weit klar.


    Die Version meiner Firmware lautet lt. C64 "v 1.0.0atenrdead0-20".


    Da ich im laufe meiner Programmiertätigkeit am 6502, 8051, AVR und Cortex auch meine Erfahrung bezüglich SD-Karten sammeln konnte, weiß ich, das manche Karten sehr pingelig sind, was die Initialisierung angeht - und das SDHC/XC-Karten im Gegensatz zu normalen SD-Karten natürlich auch eine völlig verschiedene Addressierung (Blockaddressierung vs Byteaddressierung) und teils zusätzliche Kommandos in der Initialisierung verwenden (teils sogar müssen). Daher meine Frage: Ist es bekannt, ob in der LarsP-Firmware eine solche Unterscheidung zwischen SD und SDHC implementiert ist und wenn ja, kann mir jemand sagen, wie die Initialisierungsroutine dieser Firmware für diese Karten aussieht?


    Die betreffende Karte selbst habe ich in einem anderen Projekt mit einem 8051 schon erfolgreich verwenden können, aber natürlich nur unter einer viel weitläufigeren Initialisierung, als es bei byteaddressierten Karten der Fall ist.



    Ich möchte bei der Fehlersuche ausschließen, das man sich seitens der AVR-Firmware darauf verlässt, das die SD-Karte, wenn HC, irgendwie in einen Fallbackmodus aufgrund von Standard-Initialisierungs-Kommandos fällt und dann mit der alten Adressierung gearbeitet wird, was manche Karten eventuell "nicht mitmachen".


    "Leider" bin ich nur purer Assemblerprogrammierer und kann C/C++ zwar bis zu einem gewissen Grad interpretieren, aber doch nicht alles :-(


    Edit: Bevor es zu Mißverständnissen kommt - die Frage dient nur zur Klärung des Sachverhaltes und stellt keinen "Vorwurf" an den/die Ersteller der Firmware dar - würde mir im Traum nicht einfallen.



    Viele Grüsse

    Stef

  • sd2iec unterstützt schon seit dem allerersten Release SDHC-Karten. Bisher habe ich keine Karten grösser als 256GB ausprobiert, theoretisch sollte bis 2TB alles funktionieren wenn die Karte mit FAT32 formatiert wurde.


    Formatier die Karte mal probeweise mit dem offiziellen Tool, die verwendete FAT-Library ist manchmal etwas pingelig was die Partitionstabelle und Details des Dateisystems angeht.

  • Dankeschön für den Tip - werde ich mal ausprobieren. Stimmt, das kann durchaus sein, das ich mir hier Probleme eingebrockt habe.


    Mein einziger PC-SD-Slot wird von Linux bedient, dort habe ich die Fat32-Partitionstabelle halt mit GParted erstellt und formatiert. Vorher hielt die Karte für das 8051-Projekt ein von mir zusammenkonstruiertes RAW-"Image", das mit dd draufgeschoben wurde. Vielleicht fehlen so trotz Neupartitionierung bestimmte Sektorinformationen.


    Ich habe vor langer Zeit mal eine Fat32-Library für den AVR und 8051 unter Assembler geschrieben und meine mich dunkel daran entsinnen, das es im Sektor 0/1 irgendwo auf Offset 0x1c6 herum einen Verweis auf den Virtual Boot Record gibt - wenn der fehlt oder falsche Infos enthält, kanns durchaus sein, das man letztenendes keinen Zugriff aufs Dateisystem erhält.

  • Ich hatte bislang auch keine Probleme - bis ich halt auf eine andere Karte ausweichen musste. Der Slot selbst liegt auf einer üblichen Adapterplatine und klemmt über ein Verbindungskabel am AVR. Da ich die Verbindungen ab Slot bis hin zum AVR und Spannungsversorgung bereits zu Beginn der Problematik durchgemessen habe, kann ich elektrische Probleme auch ausschließen.


    Höchstens, die Kontaktpins -im- Slot haben Probleme, aber das wäre nach vielleicht 30 mal einschieben einer Karte der Hammer, wenn die jetzt schon Probleme machen würden.

  • Hat sich bislang erledigt - bei erneuter Überprüfung der Signalverbindungen habe ich vor lauter Tran die Steckverbindung zwischen AVR und Adapter um einen Pin versetzt wieder aufgesteckt, so das letztlich 5V auf dem 3.3V Anschluss des Adapters landeten, dabei die dazugehörige Masse vom AVR I/O gezogen und die Karte gegrillt wurde - heiße Angelegenheit, die Fingerkuppe dankt.


    Merke: Steckverbindungen nur mit Wannenstecker.....

  • ... bei erneuter Überprüfung der Signalverbindungen habe ich vor lauter Tran die Steckverbindung zwischen AVR und Adapter um einen Pin versetzt wieder aufgesteckt, so...

    Merke: Steckverbindungen nur mit Wannenstecker.....

    Jo. Und merke auch... das, was man Ausschließt ist die Fehlerquelle. Denk Dir nix. Ich glaube das geht jedem so. ^^


    Stefan

  • Der Slot selbst liegt auf einer üblichen Adapterplatine und klemmt über ein Verbindungskabel am AVR. Da ich die Verbindungen ab Slot bis hin zum AVR und Spannungsversorgung bereits zu Beginn der Problematik durchgemessen habe, kann ich elektrische Probleme auch ausschließen.

    Hast du bei diesem Kabel möglicherweise die Pinbelegung optimiert und nur eine GND-Leitung verwendet? Es gab vor langer Zeit schonmal im Forum hier so einen Fall wo das gemacht wurde und es damit Probleme beim Kartenzugriff gab, weil das zu Übersprechproblemen auf dem Flachbandkabel führte. In deinem Fall könnte eine Karte toleranter sein oder weniger steile Signalflanken verwenden als die andere.


    (anders als in vielen andere Microcontroller-SD-Routinen werden in sd2iec die CRCs nicht abgeschaltet sondern beim Senden berechnet und beim Empfang geprüft)

  • Gute Idee und danke für den Tip, ich hab allerdings beide GND-Leitungen auf der jeweils gegenüberliegenden Seite verwendet. Das ist noch die Ausführung mit dem dicken Slot, jene, die man heute vornehmlich bekommt, ist für Micro-SD gedacht, die hat nur noch eine GND-Versorgung.


    Ich glaube, ich bau das Ding einfach nochmal auf, falls sich die andere Karte auch stur stellen sollte.


    Was ich mir auch überlege, ist, vielleicht eine Variante mit einem 8051 zusammenzuklöppeln; das braucht allerdings einige Zeit, bis ich das funktionsfähig hätte. Ein bissel Kenntnisse im Umgang mit dem IEC-Protokoll und Kommunikation zwischen 8051 und einer 1570 habe ich schon (habe mal einen Diskettenreader zusammengebaut, der über den 8051 und eigenen Floppyroutinen in der 1570 Daten über den seriellen Port zum PC schiebt) , FAT32-Librarys hab ich auch schon zusammengetackert, ist halt alles Assembler.


    Der 8051 hätte halt den Vorteil, das seine Ports von Grund auf bidirektional sind, nachteilig ist, das meine 8051-Varianten leider nur ca 1KB internen SRAM haben und ich mir für so eine Konstruktion externes SRAM eigentlich gerne sparen würde. 1KB ist ein -bissel- arg wenig, wenn man bedenkt, das man schon einen 2*512 Byte großen Transferbuffer vorhalten müsste/sollte/muss. Plus der Umgang mit Speedern & Co händeln. Ich habe zwar auch eine 6510-Emulation für AVR und 8051 zur Hand (auch mal selbstgeschrieben, war als Drop-In-Replacement gedacht), mit der ich vielleicht eine halbe Floppy emulieren könnte, aber parallel dazu die SD-Karte händeln und verständlich für die Emulation übersetzen wird wohl äußerst kompliziert. Für einen äußerst "dummen und lahmen C64" mit S/W-TV-Ausgabe und sehr beschänktem RAM, "ohne alles", hat die Emulation mal gereicht.


    Und obs insgesamt bei all den gegebenen Floppyemulationsvarianten noch Sinn macht, weiß ich auch nicht.


    Das wäre wohl eher eine "just for fun"-Beschäftigung, über mindestens Ostern hinweg.

  • Hast Du gar keine Widerstände an CS, MOSI und SCLK?



    Ich habe schon sehr viele SD2IEC's nach obiger Schaltung gebaut, ich nutze auch die steckbaren SD-Module, allerdings entferne ich noch die Pullup-Widerstände, die sich auf diesen Modulen befinden.

    Wenn man die Slots für Micro-SD-Karten benutzt, so kann man diese direkt an den Atmega anschließen, denn auf deren Platine sitzt ein Leitungstreiber IC.

  • Capstan: Hehe, ich kann vermuten, worauf du hinauswillst- ja der 8580 in dem 250425 klingt gut, weil er mit 9V von einem Spannungsregler versorgt wird :-) Der wurde dort reingeimpft, weil der vorhandene 6581R4AR den Geist aufgab.

    Aufgrund Mangel an den üblichen Commodore-Fußwärmern - und da ich noch ein paar andere 64er habe, die versorgt werden wollen - hab ich diese Kiste probehalber auf Single-12V und drei DC-DC-Wandlern umgebaut. Ich muss allerdings noch die 50 Hz generieren und ein bischen nach Integration von den fetten Kondensatoren schauen, die zzT nicht wirklich eine arg große Rolle spielen.

    CapFuture1975: Ja, richtig, ich hab keine Pullups direkt auf dem Board, nutze dafür die auf dem Slot. Die Konstruktion ist die absolute Sparvariante, selbst ohne externem Crystal, da ich davon ausgehe, das der Drift des internen Oszi ist mMn nicht so hoch, als das es da großartig Schwierigkeiten geben würde. Besser wäre es, aber ich muss mit den Teilen haushalten, die ich habe. Selbst der 1284 ist schon ziemlich runtergenudelt, wie man sieht, aber die sind teuer. Gerade heute.

  • Echt? Hab hab das nach den Layout (ohne Taster) aufgebaut.


    https://mingos-commodorepage.c…Bau%20dir%20dein%20SD2IEC!


    Ein guter Hinweis, so werde ich tun.


    Edit. Ich bin gerade extrem verunsichert, was mein Wissen bzgl AVR und SD Karte angeht. Eigentlich kenne ich das nicht anders, als MOSI/MISO/SCLK ggf, falls nötig, mit Pullups zu versehen. Ich weiß zwar, das man im AVR die internen -Pullups- "deaktivieren" und externe Pullups verwenden kann, aber ich komme gerade nicht damit klar, wo und wie ein externer Pulldown Einfluss findet.

  • Echt? Hab hab das nach den Layout (ohne Taster) aufgebaut.


    https://mingos-commodorepage.c…Bau%20dir%20dein%20SD2IEC!

    Auf der Seite wird sogar extra das hier erwähnt: Falls ein anderer SD-Karten Slot verwendet wird, VORSICHT: Ein Levelshifter/Pegelkonverter (5V -> 3,3V) muss sich bereits auf dieser Platine befinden.


    Nur doof, das auf dem dort verlinkten Slot überhaupt kein Level-Shifter drauf ist, da sind nur Pullup-Widerstände und ein Spannungsregler drauf.


    Jedenfalls sieht die Original LarsP-Schaltung Pulldown Widerstände vor:



  • Ja, den Kartenadapter, wie er in seinem Design verwendet, habe ich ebenfalls.


    Also, ich kenne die Beschaltung des Adapters nicht, ich habe auch gerade keinen externen mehr zur Hand, aber es muss ja zumindest auch eine Signal-Pegelwandlung darauf statt finden, anderenfalls würde mir die Karten reihenweise abrauchen. Ich sehe nur in dem Design, das er die Widerstände zwischen CS, MOSI und SCLK wohl dazu verwendet, um auf den 3.3 Volt Signalpegel zu kommen - das muss man bei dem gegebenen Adapter ja nicht.


    Es wäre natürlich etwas anderes, wenn ich eine SD-Karte direkt ohne irgendwas drumherum mit dem SPI-Interface verbinden würde. Dann wäre es klar, das ich so vorgehen müsste.


    In jedem Falle verwende ich den Adapter so, wie er ist, auch klaglos in meinen eigenen Designs um 5V herum.

  • Du hast vollkommen recht, es sind Pullups auf 3.3 Volt und die Signale landen direkt an der Karte. Ein maximaler Fehler auf meiner Seite. Verwunderlich, das es bislang überhaupt so funktioniert hat. Danke für diesen extrem wichtigen Hinweis! Ich hab mich drauf verlassen, das wenigstens eine Pegelwandlung darauf statt findet - (edit: hierfür habe ich die Widerstände auch angesehen).


    Der Slot fliegt raus und wird durch den Micro-Slot ersetzt !


    DA

  • Das wird auch hier behandelt:

    https://www.eevblog.com/forum/…-please-explain-this-one/

    Und gerade der Punkt:

    "

    A lot of 3.3V CMOS processes have 4.6V absolute maximum ratings. That's within -10% of 5V that, given a below-spec 5V supply and natural process variation, the device may be able to survive for some time at that voltage, but it's definitely not recommended and many will die.

    (Unfortunately, the specifics of device reliability vs. supply voltage for a given process is notoriously difficult to find. Manufacturers seem to like leaving such things unsaid.)"

    Das müsste man "Mingos" eigentlich mitteilen, das hier ein potentieller Fehler vorliegt - falls er hier nicht mitliest. Ich hätte ihn auf seiner Webseite angeschrieben, aber die Kontaktfunktion ist nicht aktiv und ich habe keinen Twitter-Account.