FREE MicroSD IEC (DIP/SMD)

Zitat von kinzi

Das ist kein "Hack", das ist Verwendung des Bauteils, wie es gedacht ist (Open Collector). Das gleiche Argument könntest du bei einem 7406/7407 am Userport als Buffer bringen, und diese Schaltung wurde dutzendfach verwendet.. Diese Gefahr bannst du nur, wenn du Optokoppler oder Relais einsetzt, dann hast du völlige Trennung der Kreise.

Man kann solche Risiken durch das Design ausschalten. Wenn man beim SD2IEC den BUS und AVR mit TTL-Pegel (5V VCC) betreibt, hat man das Risiko der Defekte in Kette schon ausgeschaltet. im Ausgangspost wurde alles richtig gemacht.

Natürlich sollte man I/O am Userport immer per Optokoppler trennen, wenn man z.B. Lasten damit schalten möchte. Was da früher gebaut wurde, sollte man wirklich nicht als Referenz verwenden. Und wenn sich zwei TTL-Pegel gegenüberstehen, kann man mit dem Treiber auch mal Pech haben, aber meist legt der beim Defekt nur etwas fest.

Es ist beim Schaltungsdesign nicht nur die Frage: geht das so. Man sollte auch bedenken wie sich Bauteile verhalten können und was im "worst case" passieren kann.

Zitat von kinzi

Es funktioniert prma. Keine Ahnung, warum alles mit diesen Fet-Level-Shiftern herumeiert.

Zitat von cbmhardware

Solche Hacks funktionieren oft, haben aber auch immer ein Restrisiko. Wenn der Treiber mal irgendwo voll durchlegiert, was nicht so unüblich ist, dann kann man sich von den 3.3V-Bauteilen dahinter verabschieden.

Dann lernt man spontan warum so etwas in einem guten Design nichts verloren hat.

hallo cbmhardware , ich vermute, du meinst die level shifter. da kann es die großen probleme geben.
und treiben können die ja oft, die meisten schaltungen, ja nicht. nur den pegel anpassen.

ich gehe davon aus, dass du nicht die 74xx treiber meinst, die sind dafür gebaut und gedacht.
manch einer (7406/7407) sogar bis 30V und wie bereits von kinzi und mir geschrieben,
auch ab einem 2v highpegel, dafür ideal geeignet.

ich wüsste da keine bessere und einfachere und günstigere lösung?

gruß
helmut

aber widerum, würde ich, wie auch du geschrieben hast, möglichst auch den avr mit 5v betreiben.
damit man später, wenn man es um die centronics schnitstelle erweitern möchte, nicht noch viel mehr,
als nur die paar pins an der sd karten, dann die anderen pegel anpassen und treiben muss.

so würde ich lieber die paar pins der sd-karte anpassen als die vielen anderen.
und man spart sich den spannungsregler.

aber wie bereits von mir geschrieben, man kann auch für alles, es schon vorsehen.

gruß
helmut

Die Frage ist schon mal, wo beim CBM-Bus mit seinen Pullups nach Vcc und damit einer automatischen Strombegrenzung auf ein paar mA das "Durchlegieren" überhaupt herkommen soll? Der Ausgangstransistor des 7406/7 kommt gar nie in Verlegenheit "zu legieren".

Ich bin sehr für konservatives Schaltungsdesign und gegen "auf Kante nähen", aber das ist einfach nur an den Haaren herbei gezogen.

Zitat von kinzi

Die Frage ist schon mal, wo beim CBM-Bus mit seinen Pullups nach Vcc und damit einer automatischen Strombegrenzung auf ein paar mA das "Durchlegieren" überhaupt herkommen soll? Der Ausgangstransistor des 7406/7 kommt gar nie in Verlegenheit "zu legieren".

ich glaube er meint, die sache mit dem level shifter. oft aufgebaut mit den mosfets.

du hast recht bei den ttl-treiber ics. da habe ich es auch so noch nie erlebt.
wobei dann mit einer hohen spannung. kann vieles passieren. aber dann wird ja auch eine andere lösund genauso zerstört.

ich wüsste nicht, was gegen die 7406/7407 treiber da sprechen sollte. die sind dafür ideal geeignet.

commodore hatte an vielem gespart, aber nicht an den 7406, an ihrem iec bus.

wie wohl auch oft von euch festgestellt wurde, bei reparaturen, gehen die auch mal kaputt.
aber lieber die, als andere teuere bauteile.

gruß
helmut

Zitat von axorp

ich glaube er meint, die sache mit dem level shifter. oft aufgebaut mit den mosfets.

Nein, nein, er meint meinen Vorschlag mit dem 7406/7407 als Level.Shifter und Bus-Treiber für den mit 3,3 V laufenden ATmega32.

Zitat von axorp

wobei dann mit einer hohen spannung. kann vieles passieren. aber dann wird ja auch eine andere lösund genauso zerstört.

Ja, DAS ist natürlich was anderes. Oder wenn man ein Relais direkt treibt usw.

Aber in diesem Use-Case müssen schon die Pullups "durchbrennen", damit der Ausgangstransistor abraucht. Wo soll sonst der hohe Strom herkommen? Nichts treibt den Bus direkt nach +5 V, überall sind es Pullups.

Zitat von kinzi

Nein, nein, er meint meinen Vorschlag mit dem 7406/7407 als Level.Shifter und Bus-Treiber für den mit 3,3 V laufenden ATmega32.

dann sollte er mal in ruhe darüber nachdenken. wir haben schon genug dazu geschrieben.
manchmal hängt man gedanklich irgendwo.

ich möchte nur den Matthias hier nicht verunsichern und unnötig damit aufhalten.
die ganze software erstellung ist viel aufwändiger.

so dachte ich, ich schicke ihm, damals meine zeichnung. als ich erfahren habe, dass er sich mit dem bus beschäftigen möchte.
damit keine diskusionen, über die treiber und wie wichtig die da sind, am iec bus, erst entstehen.

hat er es aber erstmal am laufen, kann er die treiber oder jeder anderer auch dazwischen klemmen.

gruß
helmut

Zitat von kinzi

Die Frage ist schon mal, wo beim CBM-Bus mit seinen Pullups nach Vcc und damit einer automatischen Strombegrenzung auf ein paar mA das "Durchlegieren" überhaupt herkommen soll? Der Ausgangstransistor des 7406/7 kommt gar nie in Verlegenheit "zu legieren".

Ich bin sehr für konservatives Schaltungsdesign und gegen "auf Kante nähen", aber das ist einfach nur an den Haaren herbei gezogen.

Jeder Leiter ist auch immer induktiv und man kennt das Kabelrupfen beim eingeschalteten Gerät. Da können ordentliche Spitzen entstehen, abgesehen davon kann ein altes Bauteil auch durch Korrosion im Sockel, kalte Lötstelle oder einfach ohne erkennbaren Grund durchlegieren. Man könnte seitenweise darüber referieren, wie das bekannte Problem der festgelegten Leitungen beim Defekt am IEC-Bus entsteht.

Wenn man sich dann dahinter ein Rapberry mit empfindlichen I/Os oder ein AVR mit 3.3V-Versorgung befindet, hat man durch die Fahrlässigkeit einen ärgerlichen Defekt. Das ist nicht bei den Haaren herbei gezogen, das ist wirklich sehr triviales Grundwissen.

Zitat von axorp

dann sollte er mal in ruhe darüber nachdenken. wir haben schon genug dazu geschrieben.
manchmal hängt man gedanklich irgendwo.

Kein Thema, geht mir oft genug selbst so.

Zitat von axorp

ich möchte nur den Matthias hier nicht verunsichern und unnötig damit aufhalten.

Richtig, eigentlich wollte ich schon gar nichts mehr dazu schreiben, aber ...

Matthias macht das für sein Projekt, wie er es richtig findet. Wenn er es dann freigibt, kann ich es ja immer noch für mich so machen, wie es mir (besser) gefällt.

Zitat von cbmhardware

Wenn man sich dann dahinter ein Rapberry mit empfindlichen I/Os oder ein AVR mit 3.3V-Versorgung befindet, hat man durch die Fahrlässigkeit einen ärgerlichen Defekt. Das ist nicht bei den Haaren herbei gezogen, das ist wirklich sehr triviales Grundwissen.

ja, ich wollte eigentlich hier nichts mehr schreiben um den matthias zu verunsichern.
erstrecht wollte ich nicht, dass man glaubt, dass du falsch liegst, nein bei manchen dingen hast du ja recht.
es ist ja hier auch öffnetlich und besonders für später ist auch unsere diskusion, für andere interessant.
damit man etwas leren kann.

so hast du ihr auch recht, ich vermute so sieht es auch kinzi, dass man möglichst alles nur mit einem pegel betreibt.
so würde ich lieber, wie bereits, ein paar mal geschrieben. den atmega auch mit 5v betreiben
und nicht mit den 3,3v, nur wegen der SD karte die selbst noch nicht mal treiberproble usw. hat.
wie ein extrener bus mit langen kabeln und mehreren geräten am bus.

man muss auch bei den heutigen ics bedenken, da diese intern die schutzdioden eingebaut haben.
dass eine überpspannung, an z.b. einem io-pin, intern im ic, auf die masse oder die versorgungsspannung
abgeleitet wird. da es auf dem chip gemacht wird. können viele probleme oder defekte später entstehen.

so muss man das auch bei den neueren ttl cmos serie (74hc,hct,ac,act usw.) mit berücksichtigen.
die haben intern auch schon die schutzdioden eingebaut. so kann es sein, dass ein altes ttl-design,
für die s, ls usw serie, mit den neuen ttl-ic probleme macht.

ich hoffe dass auch matthias aus unserer diskusion, im nachhinein, etwas lernt.
falls er es nicht schon alles kennt. so muss ich hoffentlich kein schlechtes gewissen haben,
dass wir ihn bei der softwareentwicklung unnötig aufhalten.

aber es wir manch einen geben, den es interessiert und der hier etwas dazu lernt.

Zitat von kinzi

Matthias macht das für sein Projekt, wie er es richtig findet. Wenn er es dann freigibt, kann ich es ja immer noch für mich so machen, wie es mir (besser) gefällt.

ja, so sehe ich es auch, den die ganze programmierung, ist viel arbeit.

auch wenn ich mich, nun vor fast 20 jahren, eigentlich sofort als der atmel avr herauskam,
mit ihm beschäftigt und ihn programmiert habe. würde ich es nun nicht mehr so einfach hinbekommen.

den 2005, habe ich aufgehört zu programmieren. und ich müsste erstmal hunderte stunden investieren.

baer die neuen microcontroller, die hardware sehe ich mir immer noch gerne an,
so nach dem motto, was würde ich heutzutage damit alles anfangen und manche alten sachen auch nun viel einfacher bauen.

wir warten ab, was matthias da macht und mit welchen schönen neuen ideen er uns wieder überrascht
und wir wollen seinen taten und schaffensdrang garnicht behindern

Zitat von Matthias

Ja, was soll ich sagen, es funktioniert. Den 3.3V Regler habe ich durch 2 Widerstände ersetzt, vorher den Strom gemessen die die SD-Karte benötigt (10-40mA), und dann das Sketch laufen lassen, ob die SD-Kare erkannt wird. Man muss die Spannung mit dem Spannungsteiler genau treffen, sowie die Widerstände natürlich so wählen, dass man keine Heizung erzeugt, aber immer noch soviel, dass die SD Karte sauber funktioniert.

Das habe ich dann 1 Stunde laufen lassen (ständig das Directory eingelesen). Heraus kam dann 47 Ohm und 150 Ohm. Dabei werden die Wiederstände unmerklich warm. Vorher hatte ich es mit 100 Ohm und 33 Ohm probiert... keine gute Idee

bitte bedenke, ohne einen regler oder mindestens zwei oder drei dioden in serie, die die
5v stabilisierte spannung, um die druchlasssapnnunge der dioden, um jeweils ca. 0,7v, und einen elko.
würde ich es nie machen.

warum und wiso:
deine widerstände, als spannungsteiler, sind von dem stromverbrauch der sd-karte abhängig.
dass hast du ja gemerkt. nur es gibt alte und neue typen. da schwankt der stromverbrauch extrem.
was aber noch viel schlimmer ist. der stromverbrauch der sd-karte schwankt extrem, im betriebszustand.
würdest du dir die spannung, da mit einem oszi ansehen, dann ist das nie und nimmer eine
stabile gleichmässige spannung. dass geht so wirklich nicht lange gut.
da bekommt manch einer nur unnötige probleme später.

am günstigsten ist es wohl, mit den zwei oder drei dioden, die die stabilisierte spannung senken.
dass schwankt auch etwas, weil die durchlassspannung auch von dem durchlassstrom abhängt.

heute kostet ein kleiner spannungsregler nicht mehr viel und benötigt oft weniger platz, als die dioden.
so wäre es auch am sichersten. den gibt es auch im to92 gehäuse oder in smd. ich würde beide vorsehen.
so kann jeder dass nehmen was da ist. benötigt ja auch nicht mehr platz,
da man die lötpads ineinander setzen kann.

Zitat von Matthias

Ein Quarz wäre zwar toll und stabiler, gerade was USB und Serial-Port angeht, doch da es mit dem ATMega32 auch ohne Quarz und mit internen 8Mhz funktioniert, wollte ich es mit dem ATMega 328P auch so probieren... was funktionierte. Bei 8 Mhz kann man USB natürlich vergessen, deshalb auch die nach aussen geführten RX/TX Pins, der als Bug-Hunter Port ausreichend mit 115200 funktioniert (beim ATMega32 konnte man 115200 nicht benutzen).

ich würde beides vorsehen, wenn platz ist, dann den quarz und die beiden kondensatoren dazu.
so kann man es später jederzeit erweitern. optional noch einen quarzoszillator. muss aber nicht sein. da oft zu teuer.

Zitat von Matthias

Aber da ja noch ein OLED-Display angeschlossen werden soll, hätte man so auch nochmal eine Bug-Hunter Anzeige. Ob das alles dann so läuft und benutzbar ist wie ich mir das vorstelle... wird der abschließende Test zeigen. Bisher bin ich mit den Vorabtests sehr zufrieden.

was ist eine bug-hunter anzeige?

Zitat von Matthias

Es kann aber sein das ich alles auf externe 16 Mhz umstelle... ich lass mich da selbst überraschen.

wenn du die zwei pins fürs quarz und die beiden kondensatoren vorsiehst, dann ist es auch später kein problem.
dass kann auch in smd sein.

wenn du dein iec bus timing gut implementierst, dann gibt es da auch keine timing probleme.
commodore hat, mit dem 6500/1 microcontroller, dass damals mit 1mhz, 1 oder 2kbyte und nur ein paar byte gemacht.
um den kompletten iec bus und den ganzen plotter mit allem drum und dran zu steuern.

ich habe den vc1520 schaltplan gerade gesucht und mir ihn angesehen.

da benutzt commodore auch wieder die 7406 treiber für den iec bus.
und auch die atn ack = atna = attn leitung um den bus sofort in echtzeit zu blokieren benutzen die wieder.

ich habe es mit den zwei dioden und dem massewiderstand gelöst, damit dafür kein extra ic benötigt wird.

damit man da schon keine timingprobleme bekommt und auf jeden fall keine interrupt ressourcen
und speicherstellen damit verschwendet.

vc1520 - schaltplan.pdf

die 74ls14 benötigst du nicht unbedingt, dass macht ja dein avr.
wobei wären die da, dann wäre der atmega, besser vom iec bus geschütz.

gruß
helmut

Zitat von Matthias

deshalb auch die nach aussen geführten RX/TX Pins

was ist aber bug-hunter?

ich habe nochmal gegoogelt.
hat es mit der fehler suche, mit dem einfachen debuggen zu tun?

falls es so ist, dann und ich liebe es so
dazu ist die serielle ideal. man gibt einfach seine schritte, seine daten, seine variablen,
seinen unterprogramm einsprung usw. einfach über ein terminal aus. so sieht man gut dann, wo es hakt.
zum schluss setzt man sein flag und compaliert es nicht mehr mit.
so kann man dann sehr einfach etwas untersuchen, ausgeben und auch eingeben, oder abfangen.
besonders bei der entwicklung. man gibt den inhalt einer variablen zum terminal aus, macht einen stop.
so kann man sich überzeugen ob es nun ok ist. falls nicht gibt man einen geänderten wert,
über die tastatur ein usw. so hat man einen guten überblick über seine ganzen routinen.
und sieht sofort, wo der microcontroller zuletzt hängen geblieben ist.

schon in den 80er, waren für mich, rxd und txd die wichtigsten pins,

die ich erstmal nicht für andere sachen belegen wollte.
nur im notfall und dann oft mit einer zwischen oder umschaltung.
ich habe damals schon darüber eine drahtlose infra rot kommunikation gemacht.
da reichen auch 2400 boud. die ca. 240 zeichen pro sekunde, dass schafte damals z.b. kein normaler drucker.
erstrecht konnte kein mensch, so schnell etwas eintippen. da reichen sogar 120 boud

gruß
helmut

edit....
nun komme ich wohl langsamm selbst auf den trichter und verstehe wohl auch das:

Zitat von Matthias

der als Bug-Hunter Port ausreichend mit 115200 funktioniert

dann benötigst du aber keine 115200 boud = 11520 byte pro sekunde dafür.

noch nicht mal um eine inteligente anzeige zu steuern.
dass geht auch viel langsammer. ich machte es 48 mal langsammer mit 2400 boud.

dann kannst du es ganz einfach mit einer IR diode als sender und einem dreibeinigem IR-empfänger machen.
(dass habe ich aber nun schon fast vor 10 jahren hier irgendwo auch mindestens einmal erwähnt)

dafür habe ich auch drei verschieden typen in deine bastelkiste gelegt. auch eine kleine smd version.
wenn du damit auch erfahrung sammeln möchtest, dann lege ich von jedem 10 stück noch rein.

und ich hoffe dann irgendwann, dass du es sogar, mit infra rot schaffen würdest, eine 1541 kabellos zu verbinden.
dass habe ich damals schon gemacht um die drucker kabellos zu verbinden.
nur das timing, besonders dass automatische handshake ist dann erstrecht wichtig.
weil dann kann man den iec und den ieee488 bus sogar in einzelschritten, ohne datenverlust, machen.
so kann man die einzelne bitübertragung schritweise mit einem taster sich mit leds ansehen usw.

wenn der c64, die atn leitung auf low zieht, weil er ja anfangen möchte etwas zu übertragen.
wird sofort über das gatter, von der z.b. floppy, die datenleitung hardwaremässig auch auf low gezogen.
so blokiert automatisch erstmal der bus. weil bevor der c64 dann weiter machen möchte mit dem takt.
er vorher prüft ob ein langsammes gerät, die datenleitung auf low gezogen hat.
weil es ja eine pause benötigt. weil es noch intern beschäftigt ist. so z.b. die 1541 mit ihren interne sachen.
dann wartet der c64 solange bis die data leitung wieder freigegeben wird, also high geht.
nun weis er alle paralle geschalteten geräte, an dem iec bus, sind nun empfangsbereit.
so bestimmt immer das langsammste gerät am bus, die geschwindigkeit.
deswegen ja auch eine parallele open collector verknüpfung am bus.
erst wenn der letzte es freigibt, somit nicht die leitung auf low zieht, geht es weiter mit der übertragung.

vom tobias csdragon ist ein paket, an mich unterwegs, er wollte dich auch unterstützen.
so sind da auch 10 kleine lcd displays für dich dabei. und andere bauteil.
ich suche noch ca. eine woche weiter in meinen kellern und sende es dir komplett, mit seinen teilen zu.
damit du etwas zum experimentieren hast.

die 7406 und die 7407 usw. muss ich noch suchen, schicke dir mal je eine stange davon zu.

lg
helmut

Zitat von axorp

nur das timing, besonders dass automatische handshake ist dann erstrecht wichtig.
weil dann kann man den iec und den ieee488 bus sogar in einzelschritten, ohne datenverlust, machen.
so kann man die einzelne bitübertragung schritweise mit einem taster sich mit leds ansehen usw.

wenn der c64, die atn leitung auf low zieht, weil er ja anfangen möchte etwas zu übertragen.
wird sofort über das gatter, von der z.b. floppy, die datenleitung hardwaremässig auch auf low gezogen.
so blokiert automatisch erstmal der bus. weil bevor der c64 dann weiter machen möchte mit dem takt.
er vorher prüft ob ein langsammes gerät, die datenleitung auf low gezogen hat.
weil es ja eine pause benötigt. weil es noch intern beschäftigt ist. so z.b. die 1541 mit ihren interne sachen.
dann wartet der c64 solange bis die data leitung wieder freigegeben wird, also high geht.
nun weis er alle paralle geschalteten geräte, an dem iec bus, sind nun empfangsbereit.
so bestimmt immer das langsammste gerät am bus, die geschwindigkeit.
deswegen ja auch eine parallele open collector verknüpfung am bus.
erst wenn der letzte es freigibt, somit nicht die leitung auf low zieht, geht es weiter mit der übertragung.

Alles anzeigen

ich habe hier nun nochmal extra mich zitiert, über den iec bus,
damit es oben in meinem bla bla nicht untergeht.

besonders wenn es einen anderen interessiert.
so könnte ich irgendwann später eine abwandlung meines iec interfaces zum spielen und testen mal machen.

wenn ich einen layouter finde. so kann man, seine eigen iec oder ieee488 erfahrung machen.
mit ein paar ttl-ics und einem eprom als pla, mit bauteilen für unter 5 euro.

da meine interfaces voll ttl-basiert sind, sind die so schnell, dass sie parallel zu den vorhandenen geräten,
sogar mit der gleichen geräte nummer betrieben werden können und somit die geräte nicht behindern.

wenn man es nicht dann sogar extra möchte

so könnte man die übertragung, dann zwischen einem drucker oder der 1541 zum c64, in einzelschritten,
schön gemütlich, mit vielen leds und viel blink blink, beobachten und studieren.

so eine 1byte übertragung, pro sekunde, hat was beruhigendes auch an sich.
so kann man dann sein geladenes programm, von der 1541, erst nach stunden starten
hier geht es nicht darum, wie schnell schaffe ich es, über den bus, von der floppy zu laden,
sondern wie langsamm schaffe ich es. so gibt man load ein und ein paar tage später wurde es erst geladen

dann wäre auch eine eigen spätere iec bus entwicklung einfacher zu beobachten und zu testen.
wenn es überhaupt einen interessiert.

gruß
helmut

Ich frag mich nur, warum man nicht z. B. einen stm32 nimmt? Der wäre zur iec Seite auf den meisten Pins 5v tolerant, arbeitet aber zur sd Karte hin gleich mit 3,3v, braucht also keine Shifter? Ausserdem ist er doch sogar billiger als der AtMega?

Zitat von daybyter

Ich frag mich nur, warum man nicht z. B. einen stm32 nimmt? Der wäre zur iec Seite auf den meisten Pins 5v tolerant, arbeitet aber zur sd Karte hin gleich mit 3,3v, braucht also keine Shifter? Ausserdem ist er doch sogar billiger als der AtMega?

was kostet ein stm32?
ich er auch so leicht und überall erhältlich, wie ein atmega?

aber die treiber benötigt man ja sowiso für den iec bus.

Na so ein Board z. B.

https://www.ebay.com/itm/1Pc-S…46ee5c:g:tPsAAOSw9CNe32yH

Zitat von Matthias

Was etwas verwirrend war ist die umgekehrte Signalschreibweise bei IEC (0 = True und 1 = False).

Das ist z. B. dem Umstand der invertierten Logik auf dem Bus (Ruhezustand = 1) und des verwendeten "wired OR" (mehrere 7406-Ausgänge mit OC parallel) als Bussystem zusammen. Das ist ja durchaus üblich, vergleiche im C64 /NMI, /IRQ oder die Chip-Selects.

Zitat von Matthias

Man muss die Spannung mit dem Spannungsteiler genau treffen, sowie die Widerstände natürlich so wählen, dass man keine Heizung erzeugt, aber immer noch soviel, dass die SD Karte sauber funktioniert.

Das würde ich in der Versorgungsleitung nicht machen. Da ist @axorps Vorschlag mit DIoden in Reihe (oder alternativ einer LED) wesentlich besser. Ist zwar auch noch stromabhängig, aber durch die steilen Diodenkennlinien nicht mehr so arg.

Zitat von Matthias

Ein Quarz wäre zwar toll und stabiler, gerade was USB und Serial-Port angeht, doch da es mit dem ATMega32 auch ohne Quarz und mit internen 8Mhz funktioniert,

Kann man machen, allerdings hatte ich bei ATmega8 selbst schon solche Exemplarstreuungen, dass daraus abgeleitete Signale (erzeugte Töne) nicht mehr genau genug gestimmt haben und es nicht funktioniert hat. Sogar einen Fall, bei dem die serielle Baudrate zu stark "daneben" war habe ich mal gehabt. Mag sein, dass man das wegoptimieren kann, aber ich würde hierfür einen Quarz nehmen.

Darf ich mal ganz blöd dazwischen fragen? Ich bin mir nämlich nicht ganz sicher, ob ich richtig verstanden habe, was das Ziel des Projektes ist. Ein "SD2IEC-light"? Wird das irgendwelche Vorteile gegenüber einem herkömmlichen SD2IEC haben?

Versteht mich bitte nicht falsch, das soll kein Nörgeln sein, ich bin nur neugierig. Die Antwort "Weil ich es kann." auf die Frage "Warum?" war für mich in diesem Hobby immer vollkommen ausreichend.