Projektvorstellung: xlink -- Datentransfer PC <> C64 über usb/parport für x-dev und mehr

Es gibt 99 Antworten in diesem Thema, welches 25.276 mal aufgerufen wurde. Der letzte Beitrag (6. August 2022 um 20:47) ist von bigby.

  • Ok, danke. Wenn es bei vier verschiedenen C64 nicht klappt liegt es wohl nicht an den CIAs.

    Ich habe hier avr-gcc 5.2.0. Sollte aber auch mit einem früheren gehen. Wenn nicht, wie lautet die Fehlermeldung?

    Anbei mal eine Firmware mit um 2ms verlängertem low beim Strobe, vielleicht reicht das ja...

    Welche assys und CIAs sind das bei deinen C64?

    Thomas: Danke für die Info. Im von mir konsultierten Schaltplan (C64 intern) finde ich keinen C an FLAG2 (?), ist der u.U. erst später hinzugekommen? Wenn ja habe ich den nicht in Betracht gezogen.

  • Thomas: Danke für die Info. Im von mir konsultierten Schaltplan (C64 intern) finde ich keinen C an FLAG2 (?), ist der u.U. erst später hinzugekommen? Wenn ja habe ich den nicht in Betracht gezogen.

    Ja, der Kondensator kam wohl erst später dazu. Enthalten ist er mindestens in der C64C-Version (die flache Version mit der 64poligen PLA) enthalten (C6). Im C64-Reloaded wurde er auch übernommen (C79).

    Meine Projekte:
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

  • 1. Ja eigener Thread wäre wohl angebracht.

    2. Ja, R12 ist 820 Ohm schon 5x überprüft

    3. Korrekt, vor R12 dem 820 Ohm Widerstand ist das Signal schön rechteckig und ca. 250ns lang.

    4. Reicht das aus, um das /FLAG2 Signal zu triggern?

    Wem ein leeres EPROM fehlt, braucht ein EPROM-Lösch-Gerät

    Mein GitHub: Bitte melde dich an, um diesen Link zu sehen.
    EasyFlash3 DIY: Bitte melde dich an, um diesen Link zu sehen.

    Mein Discogs: Bitte melde dich an, um diesen Link zu sehen.

  • Vorausgesetzt deine Boards haben alle den C6 mit 470pf bräuchten wir rein rechnerisch mindestens 300ns, um über 820Ohm von 5v auf die Obergrenze für low von 2.4 Volt zu kommen -- also ist die Zeit für strobe-low wohl zu kurz.

    Bitte probier mal die firmware mit dem delay aus. In jedem Fall muss ich da die Zeiten erhöhen, denke ich.

  • @Henning:
    Die Signale schauen nun viel besser aus!

    - Ping funktioniert nun ;)
    - Mit Peek kann ich Werte auslesen ;)
    - Mit Poke kann ich Werte schreiben ;)
    - identify geht auch (XLINK 1.0 C64 ROM $F547-$FB42)
    - fill geht

    - Benchmark erzeugt mir einen leeren, hellblauben Bildschirm

    Wem ein leeres EPROM fehlt, braucht ein EPROM-Lösch-Gerät

    Mein GitHub: Bitte melde dich an, um diesen Link zu sehen.
    EasyFlash3 DIY: Bitte melde dich an, um diesen Link zu sehen.

    Mein Discogs: Bitte melde dich an, um diesen Link zu sehen.


  • Vorausgesetzt deine Boards haben alle den C6 mit 470pf bräuchten wir rein rechnerisch mindestens 300ns, um über 820Ohm von 5v auf die Obergrenze für low von 2.4 Volt zu kommen -- also ist die Zeit für strobe-low wohl zu kurz.

    Bitte probier mal die firmware mit dem delay aus. In jedem Fall muss ich da die Zeiten erhöhen, denke ich.

    Interessanter Punkt.

    Meine C64, auf denen ich XLink bis jetzt laufen ließ, waren alles "Brotkasten"-C64, hatten also keinen Kondensator...

    Frage in die Runde: Gibt es jemanden, der das Original-XLink auf einem C64C oder C64R betreibt?

    Gruß,
    Thomas

    Meine Projekte:
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

  • Den Strobe kann man aber nun ruhig etwas kürzer machen. 3us sollten reichen.

    Edit: hänge mal ein Oszi Bild an, dann könnte ich schauen welches Timing am besten ist.

    Ich denke mein alter 256407 hat wohl ein defektes CIA, da ging der Ping ja nur der Rest nicht.
    Bei den 3 anderen (C64C) ging der Ping nie -> zu kurzes Signal.

    Gelb: Signal nach R12
    Hellblau: Signal vor R12

    Edit: 500ns sollten auch reichen!
    Edit2: Signalfarben vertauscht!

    Bilder

    Wem ein leeres EPROM fehlt, braucht ein EPROM-Lösch-Gerät

    Mein GitHub: Bitte melde dich an, um diesen Link zu sehen.
    EasyFlash3 DIY: Bitte melde dich an, um diesen Link zu sehen.

    Mein Discogs: Bitte melde dich an, um diesen Link zu sehen.

  • Achso: Eine Kleinigkeit noch für die nächste Kernal-Version: Ein einfaches SAVE (Richtung Tape) lässt den C64 (zumindest meinen) abstürzen...

    Das LOAD von Tape wurde umgebogen und gibt einen "Disabled"-Text aus. Das SAVE sollte ebenfalls abgefangen werden...

    Gruß,
    Thomas

    Meine Projekte:
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

  • @Henning: Es funktioniert nun so ziemlich alles, außer "load" und "benchmark".

    Code
    > xlink benchmark test -v
    benchmark: -M c64 -m 0x37 -b 0x00 test  
    benchmark: trying to use usb device "/dev/xlink"...
    benchmark: using usb device "/dev/xlink"
    benchmark: using default usb device "/dev/xlink"
    benchmark: sending 28672 bytes...
    benchmark: error: transfer timeout (0 of 28672 bytes sent)
    Code
    > xlink -v load test.prg
    load: -M c64 -m 0x37 -b 0x00 -a 0x0801-0xB1F0 -s 0x0002 test.prg 
    load: trying to use usb device "/dev/xlink"...
    load: using usb device "/dev/xlink"
    load: using default usb device "/dev/xlink"
    load: error: transfer timeout (0 of 43503 bytes sent)

    Wem ein leeres EPROM fehlt, braucht ein EPROM-Lösch-Gerät

    Mein GitHub: Bitte melde dich an, um diesen Link zu sehen.
    EasyFlash3 DIY: Bitte melde dich an, um diesen Link zu sehen.

    Mein Discogs: Bitte melde dich an, um diesen Link zu sehen.

  • tulan: Ich hole morgen mal meinen C64C aus dem Schrank und gucke, ob ich das reproduzieren kann. Passiert während load bzw benchmark etwas auf PA2 (ACK)?

    Thomas: Den Absturz beim SAVE habe ich neulich bereits behoben. Ein mit der aktuellen Version 1.2 erzeugter Kernal quittiert sowohl LOAD als auch SAVE mittlerweile mit TAPE IO DISABLED.

  • @Henning: ja es tut sich in beiden Fällen was:

    Gelb: FLAG2 (Strobe)
    Blau: PA2 (Ack)

    Bilder

    Wem ein leeres EPROM fehlt, braucht ein EPROM-Lösch-Gerät

    Mein GitHub: Bitte melde dich an, um diesen Link zu sehen.
    EasyFlash3 DIY: Bitte melde dich an, um diesen Link zu sehen.

    Mein Discogs: Bitte melde dich an, um diesen Link zu sehen.

  • Ok, ich konnte das Verhalten auf meinem C64C mit 250469 reproduzieren, so wie du es beschrieben hast: Mit der bisherigen Firmware ist der STROBE zu kurz, mit 2ms delay funktionieren alle Befehle außer den Transferbefehlen (benchmark, load, save). Für die Transfers ist die Verzögerung von 2ms noch zu hoch, da greifen dann die timeouts.

    Durch Verringern des Delays auf 6 NOPs wird dieses Problem hier behoben.

    Anbei also eine entsprechende Firmware.

    tulan: Bitte probiere die firmware nochmal aus. Hilfreich wäre auch die Angabe der Assy-Nr. der boards, auf denen du testest.

    Und entschuldige bitte meinen etwas rüden Post von gestern morgen, das waren mir in dem Moment einfach zu viele Baustellen, die du da aufgemacht hattest. Schön, dass wir diesen Bug gemeinsam finden konnten. Und dank auch an Thomas für den Hinweis auf C6.

    Gruß,
    Henning

  • Die Assy-Nr. sind 250469 Rev.3 / Rev.4 und Rev. B die Brotdose war ein ganz alter 256407 (aber da ist wohl wirklich die CIA angeknackst)
    Ich probiere es am Nachmittag noch mal aus, danke.

    Wem ein leeres EPROM fehlt, braucht ein EPROM-Lösch-Gerät

    Mein GitHub: Bitte melde dich an, um diesen Link zu sehen.
    EasyFlash3 DIY: Bitte melde dich an, um diesen Link zu sehen.

    Mein Discogs: Bitte melde dich an, um diesen Link zu sehen.

  • @Henning: das Laden und Benchmark funktioniert nun auch bei mir problemlos mir Firmware 1.3.
    Ich bin überrascht wie schnell das geht, sehr geniale Sache.

    Zitat

    Und entschuldige bitte meinen etwas rüden Post von gestern morgen, das waren mir in dem Moment einfach zu viele Baustellen, die du da aufgemacht hattest. Schön, dass wir diesen Bug gemeinsam finden konnten. Und dank auch an Thomas für den Hinweis auf C6.


    Ich bin seit fast 17 Jahren Softwareentwickler, da bin ich das gewöhnt und teile auch selber gerne aus. Hab ich dir nicht böse genommen.
    Ich hoffe du meine etwas unpassenden Bemerkungen auch nicht.

    Sehr feine Sache übrigens das xlink, auf sowas hab ich schon sehr lange gewartet.

    Wem ein leeres EPROM fehlt, braucht ein EPROM-Lösch-Gerät

    Mein GitHub: Bitte melde dich an, um diesen Link zu sehen.
    EasyFlash3 DIY: Bitte melde dich an, um diesen Link zu sehen.

    Mein Discogs: Bitte melde dich an, um diesen Link zu sehen.

  • Bitte melde dich an, um diesen Link zu sehen. ist veröffentlicht.

    Hier wurde der oben diskutierte Firmware-Fehler behoben, der den Betrieb mit neueren boards (Assy. 250469 und folgende) verhindert hat.

    Ebenso wurde ein Fehler in der Windows-Version des Clients behoben, die zufolge hatte, dass bei Programmende die Windows-Meldung "Das Programm funktioniert nicht mehr richtig" ausgegeben wurde.

    Ein Update der firmware ist also nur zwingend notwendig, wenn neuere boards (C64C) verwendet werden sollen.

    Der Windows-Client kann einfach mit Hilfe des neuen Installers einfach neu installiert werden, um die erwähnte Fehlermeldung zu vermeiden.

    Gruß,
    Henning

  • @Henning:
    Ist für das xlink eigentlich ein Gehäuse geplant bzw. kann man irgend ein Standardgehäuse verwenden?
    Es würde das Ganze noch perfekt abrunden.

    Wem ein leeres EPROM fehlt, braucht ein EPROM-Lösch-Gerät

    Mein GitHub: Bitte melde dich an, um diesen Link zu sehen.
    EasyFlash3 DIY: Bitte melde dich an, um diesen Link zu sehen.

    Mein Discogs: Bitte melde dich an, um diesen Link zu sehen.

  • Hallo Gemeinde,

    ich hatte auf der letzten DoReCo meine damalige SMD-Version des Adapters Henning gezeigt und seitdem denke ich, dass ein Gehäuse für den Adapter schon sehr cool wäre.

    Also Gehäuse per 3D-Drucker drucken? Oder passende Gehäuse verwenden? Letzteres ist für mich wesentlich einfacher und darum habe ich meine SMD-Version des Adapters modifiziert, so dass er in ein "Standard"-Gehäuse reinpaßt. Sofern man dieses Gehäuse dann noch irgendwo kaufen kann...


    Folgende Anpassungen habe ich vorgenommen:

    A) Große USB-Buchse gegen Mini-USB-Buchse getauscht. Die große Buchse paßt einfach nicht für das kleine Gehäuse. Ich würde auch gerne Micro-USB verwenden, bei der Mini-USB-Buchse ist aber die Stabilität bei dicken Leiterplatten besser.

    B) Diode in die Reset-Leitung eingebaut (Anode an C64-Reset, Kathode an Atmel-CPU). Der Ausgang der CPU wird dadurch quasi zwangsweise zu einem Open-Kollektor-Output. Ein Defekt der Atmel-CPU durch gegebenfalls falsche Programmierung der Firmware ist durch die Diode ausgeschlossen.

    C) Schutzdioden für die Portpins. Die kleinen schwarzen Klötze (D2, D3, D4 und D5) enthalten jeweils 4 Dioden, wovon jeweils zwei Dioden ein Portpin gegen Spannungen größer 5V und kleiner 0V absichern. Nicht zwingend erforderlich, aber "nice to have"...

    D) Reduzierung des Widerstands in der Verbindung zum FLAG2-Eingang (Userport: Pin B) auf 180 Ohm. Ich halte die bisher verwendeten 820 Ohm für zu hoch. Begründung: Im Idealfall stellt sich am CIA-Eingang mit dem 820 Ohm zur CPU und dem Pullup-Widerstand von 3,3K-Ohm ein Low-Pegel von ziemlich genau 1V ein. Im Idealfall. Real wird dieser Wert leicht höher ausfallen, da die Atmel-CPU bei Low nicht genau 0V ausgibt, sondern ein paar zehn/hundert Millivolt darüber. Da der Herstellungsprozeß für die CIA aber NMOS oder HMOS-II ist, sollte man als Maximum für den Low-Pegel 0,8V annehmen (und nicht wie weiter oben zu lesen 2,4V (die sind für CMOS...)). Deswegen habe ich den Widerstand auf 180 Ohm reduziert, man könnte ihn auch komplett weglassen, die Gefahr das zwei Ausgänge aufeinander treffen stellt sich bei dieser Verbindung nicht. FLAG2 ist immer ein Eingang.


    Eine "Revision A" ist nebenbei schonmal in Arbeit. Mit kleinen Detailverbesserungen (z.B. breitere Stege für die oberen 3mm Bohrungen, Micro-USB und dünnere Platine (1mm), kleine Korrektur der Platinenmaße) und einem zusätzlichen Widerstand, der das Teil erstmal mehr oder minder hardwarekompatibel zum Servant64 im Thread nebenan macht. Wenn man dann die Software anpassen würde (andere CPU und andere Belegung der Pins) dann könnte man nach Lust und Laune zwischen zwei Welten (XLink und Servant64) wechseln. Oder man läßt das Pad einfach frei und verwendet die Platine nur für XLink.

    Leider verwendet das Servant64-Projekt eine andere (nicht so optimale) Belegung der acht Datenbits an der Atmel-CPU (über mehrere Ports der CPU verteilt, dadurch kann ich nicht alle Bits mit einem Befehl ausgeben). Folglich müsste man die Software anpassen, damit die Bits auch auf den richtigen Leitungen in den C64 finden...

    Bevor ich die "Rev. A"-Platine aber beim freundlichen Chinesen in Auftrag gebe versuche ich noch eine Idee mit einzubauen: Ich habe hier noch ein paar WLAN-Module (ESP8266) rumliegen und würde es sehr cool finden, wenn man auf ein USB- oder LAN-Kabel verzichten könnte und die Daten über das ESP8266-Modul überträgt. Das Teil läuft aber auf 3,3V. Bedeutet, dass neben dem Modul ein Spannungsregler und eine Pegelanpassung unterzubringen wäre. Dazu wirds aber langsam eng auf der Platine. Und ohne passende Firmware in der Atmel-CPU passiert auch nicht so sehr viel...


    Da ich aber demnächst aus privaten Gründen nicht so viel Basteln werden kann, wird die "Rev. A" ein paar Monde auf sich warten lassen...

    Ich denke der jetzige Stand muß sich aber auch nicht verstecken...

    Gruß,
    Thomas

  • Hallo Thomas!

    Ich bin begeistert :) Sehr schick. Die Idee, die Platine in ein Steckergehäuse zu bringen war mir früher auch schonmal gekommen -- Allerdings habe ich dann beschlossen, meine Platine möglichst löt- und selbstätz-freundlich zu gestalten: sowenig SMD wie möglich, dafür halt etwas größer. Mit deiner Version gibt es jetzt eine schöne Alternative, auch wenn sie etwas mehr löt-fu erfordert.

    Zu den von dir gemachten Änderungen:

    A) Mini-USB: Sehe ich ein. Für USB-A habe ich mich auch aus den oben gennannten Gründen entschlossen, das schien mir am einfachsten zu löten.

    B) Diode in Reset-Leitung: Gute Verbesserung. Ist zwar nicht unbedingt nötig (die Reset-Leitung wird durch die firmware nur zwischen tristate und low geschaltet), aber sicher ist sicher (firmware eben).

    C) Schutzdioden: Auf Schutzdioden habe ich in meiner Rev. 2 eher aus Platzgründen verzichtet. Da der Adpater ebenfalls vom C64 versorgt wird, habe ich mögliche Überspannungen aus anderer Quelle (z.B. bei Versorgung des Adapters über USB) für weniger wahrscheinlich gehalten. Ich lasse mich aber gern eines besseren belehren :)

    D) Reduzierung des Widerstandes: das werde ich für die nächsten Bausätze auch so halten (180Ohm für FLAG). Den Wert für den Widerstand habe ich zugegebenermaßen nur experimentell ermittelt... außerdem war mir der Maximalwert für den Lowpegel bei NMOS/HMOS-II hier nicht bewußt.

    Hast du die von mir in meiner Rev. 3 gemachten Änderungen für den Betrieb am C128 auch umgesetzt? Es muss für den C128 die Möglichkeit geben, die Reset-Leitung nicht am Userport anzuschließen, sondern direkt vom Board zu holen, da die Reset-Leitung am Userport des C128 nur die Peripherie zurücksetzt. Ich habe das mit einem Jumper gelöst. Fehlt diese Möglichkeit, ist es nicht möglich, am C128 einen Hardware-Reset auszulösen. Das ist für das Cross-Development allerdings exterm praktisch.

    Zur Servant64-Kompatibilität: kannst du das noch genauer ausführen? Meines Wissens benutzt der Servant ein anderes Handshaking-Schema mit dedizierter Leitung für die Richtung.

    Softwaremäßig habe ich bereits einen Servant64-Treiber für meine xlink-Software sowie eine firmware für meinen Adapter geschrieben (sprich der Servant braucht eine xlink-only-firmware). Die ist allerdings noch nicht Teil der "offiziellen" Version meiner Software. Damit lässt sich auch "nur" die xlink-client-Software (xlink.exe, xlink.dll) mit der Servant-Hardware nutzen.

    Umgekehrt (also die Servant-Software mit der Xlink-Hardware) ist denke ich aus o.g. Gründen nicht möglich.

    Die unglückliche Port-Belegung ist eher eine Folge des Arduino-Designs. Die Arduino-Bibliothek presentiert das Sammelsorium an Leitungen von unterschiedlichen ATmel-Ports als logische "Arduino-Ports". Hier musste ich auch in der Servant-Firmware die Bits aufwändig auf die eigentlichen Leitungen verteilen. Siehe Bitte melde dich an, um diesen Link zu sehen., ab Zeile 245.

    Zur Idee mit der Übertragung via ESP8266: Dazu müsste dann in der Tat eine alternative Firmware her, das sollte allerdings nicht das Problem sein, die firmware muss "nur "die CIA und den Treiber bedienen, und nur der Treiber der xlink-Bibliothek muss wissen, wie der Übertragungsweg vom PC aus verwendet werden muss. Die Xlink-Bibliothek ist vom Design her modular genug, um einfach einen weiteren Treiber für diesen Übertragungsweg aufzunehmen. Wenn es dafür die Hardware gibt, bin ich sofort dabei, das zu implementieren :) The more the merrier...

    Wie auch immer, erstmal vielen, vielen Dank für deine Arbeit! Ich kann mich Thom Braxton nur anschließen!

    :ilikeit:

  • Hast du die von mir in meiner Rev. 3 gemachten Änderungen für den Betrieb am C128 auch umgesetzt? Es muss für den C128 die Möglichkeit geben, die Reset-Leitung nicht am Userport anzuschließen, sondern direkt vom Board zu holen, da die Reset-Leitung am Userport des C128 nur die Peripherie zurücksetzt. Ich habe das mit einem Jumper gelöst. Fehlt diese Möglichkeit, ist es nicht möglich, am C128 einen Hardware-Reset auszulösen. Das ist für das Cross-Development allerdings exterm praktisch.

    Das war mir so nicht klar, dass der C128 durch Reset am Userport nicht alles zurücksetzt. D.h. Du hast einen Draht vom Prozessor aus dem C128 raus geführt und klemmst den dann auf den Jumper. Damit kannst Du dann aber nicht mehr so einfach den Adapter aufstecken und abziehen. Da sind dann immer noch extra Handgriffe nötig...

    Wäre hier eventuell eine Softwarelösung besser? Wahrscheinlich aber nicht, da dies einen angesteuerten Kernal voraussetzt. Und das ist ja bei eigenen (abgestürzten) Routinen nicht gewährleistet. Oder den C128 so modifizieren, so dass Pin 3 am Userport alles zurücksetzt...

    C) Schutzdioden: Auf Schutzdioden habe ich in meiner Rev. 2 eher aus Platzgründen verzichtet. Da der Adpater ebenfalls vom C64 versorgt wird, habe ich mögliche Überspannungen aus anderer Quelle (z.B. bei Versorgung des Adapters über USB) für weniger wahrscheinlich gehalten. Ich lasse mich aber gern eines besseren belehren :)

    Soooo dringend sind die Dioden auch nicht. Aber wenn man sie gerade zur Hand hat... Ich bin ja aber selber nicht so konsequent, um Schutzdioden mindestens an ALLE verwendeten Portpins anzuschließen. Funktionieren würde der Adapter selbstverständlich auch ohne die Dioden.

    Zur Servant64-Kompatibilität: kannst du das noch genauer ausführen? Meines Wissens benutzt der Servant ein anderes Handshaking-Schema mit dedizierter Leitung für die Richtung.

    Und deswegen wird die "Revision A" auch eine Verbindung vom Userport PC2 (Pin 8) zur Atmel-CPU (PB0, Pin 14) haben. Da man sowieso die Servant64-Firmware für die andere Hardware anpassen müsste, hab ich den am besten zugänglichen Pin an der Atmel-CPU gewählt. Deren Netzwerkanschluß ist ja nur EINE Möglichkeit, ich meine ein Betrieb über USB ist genauso möglich. Und dann würde auf dem C64 der Servant64-Kernal laufen und auf der XLink-Hardware eine angepaßte Servant64-Firmware, welche mit dem anderen Handshake klarkommt. Man könnte auch in der Firmware das Handshaking neu schreiben, aber das sprengt den Rahmen dann wohl. Da ist ein einfaches Anpassen der benutzen Portpins wesentlich einfacher...

    Die unglückliche Port-Belegung ist eher eine Folge des Arduino-Designs. Die Arduino-Bibliothek presentiert das Sammelsorium an Leitungen von unterschiedlichen ATmel-Ports als logische "Arduino-Ports". Hier musste ich auch in der Servant-Firmware die Bits aufwändig auf die eigentlichen Leitungen verteilen. Siehe Bitte melde dich an, um diesen Link zu sehen., ab Zeile 245.

    Nur für mein Verständnis: Du hast XLink auf die Servant64-Hardware angepaßt? Sehe ich das so richtig? So dass Du im C64 den XLink-Kernal laufen hast und auf dem PC mit "xlink ..." Kontakt zum C64 aufnehmen kannst? Und dazwischen ist die Servant64-Hardware?

    Zitat

    Umgekehrt (also die Servant-Software mit der Xlink-Hardware) ist denke ich aus o.g. Gründen nicht möglich.

    Genau DAS ist mein Ziel! Servant64-Kernal, Servant64-PC-Software und Xlink-Hardware dazwischen...

    Zur Idee mit der Übertragung via ESP8266: Dazu müsste dann in der Tat eine alternative Firmware her, das sollte allerdings nicht das Problem sein, die firmware muss "nur "die CIA und den Treiber bedienen, und nur der Treiber der xlink-Bibliothek muss wissen, wie der Übertragungsweg vom PC aus verwendet werden muss. Die Xlink-Bibliothek ist vom Design her modular genug, um einfach einen weiteren Treiber für diesen Übertragungsweg aufzunehmen. Wenn es dafür die Hardware gibt, bin ich sofort dabei, das zu implementieren :) The more the merrier...

    Mir wird aber wahrscheinlich der Stromhunger des ESP8266 einen Strich durch de Rechnung machen: Beim Senden können schon mal über 200mA fließen. Das möchte ich dem Userport eigentlich nicht zumuten. Mal schauen was für Alternativen es gibt. Bin ja auch erstmal in der Findungsphase...

    Wie auch immer, erstmal vielen, vielen Dank für deine Arbeit! Ich kann mich Thom Braxton nur anschließen!

    Gern geschehen. Ich will auch gar nicht irgenwie als Konkurrenz angesehen werden. Das Teil zu löten, dauert schon etwas und ist inklusive der folgenden Reinigung vom Flußmittel nicht ohne. Für den Hobbybastler würde ich in jedem Fall Deine bedrahtete Version empfehlen.

    Ist halt ein Hobby von mir...


    Gruß,
    Thomas

    Meine Projekte:
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.