Ich habe eine benutzerdefinierte PICAXE-basierte Leiterplatte hergestellt, die alle zum Programmieren des Mikrocontrollers erforderlichen Komponenten integriert. Ich nahm an, dass alles in Ordnung war, weil ich damit gut unter Windows programmieren konnte. Unter Mac OS X konnte ich es jedoch nicht programmieren. Oh, und ich verwende den WCH CH340G USB-RS232-Chip, um die Kosten zu senken, da der FTDI FT232RQ über dem 7-fachen des Preises liegt und ich nicht alle Funktionen benötige.
Ich war fest davon überzeugt, dass etwas an meinem Design elektrisch nicht stimmte, was dazu führte, dass sich der CH340G unter OSX schlecht verhielt ... Ich hatte mein Board so modifiziert, dass ich unter Coolterm einen Loopback-Test durchführen konnte und die Übertragung alle paar Zeichen einfrieren würde. Offensichtlich war etwas durcheinander und ich dachte, dass dies ein Fehler im CH340G OSX-Treiber war. Der technische Support von WCH versicherte mir, dass dies nicht der Fall sei und dass es sich um einen gefälschten Chip handeln könnte. Während dieser Hexenjagd habe ich einen handelsüblichen USB-RS232-Konverter mit dem gleichen Chip gekauft, der einwandfrei funktioniert hat. Soviel zu einem "Treiberfehler", der meine Kopfschmerzen verursacht!
Ich habe dann eine weitere Einheit mit der minimalen Anzahl von Komponenten aufgebaut, die für die Durchführung des Loopback-Tests erforderlich sind (dh keine PICAXE), und ich konnte sie an den Punkt bringen, an dem der Loopback-Test zuverlässig war und nicht mehr einfrierte. Daher ist wahrscheinlich etwas mit der Schaltung los, die das Einfrieren verursacht hat, aber im Moment könnte ich fortfahren, indem ich meine Leiterplatte mit einem Steckbrett verdrahte und die DIP-Variante für externe Komponenten verwendete, um die Programmierschaltung zu vervollständigen.
Nun zum Fleisch meiner Frage ...
Ich habe zwei Test-Setups verwendet - 1) meine Platine mit dem PICAXE an ein Steckbrett angeschlossen und 2) ein Steckbrett mit dem PICAXE und dem OTS USB-RS232-Konverter. Ich habe jeden an meinen Windows-Laptop angeschlossen und die Signale verkabelt, die meiner Meinung nach für meinen Saleae Logic 8 Pro am relevantesten sind. Ich habe die Signale beim Programmieren unter Windows erfasst, dann das USB-Kabel auf meinen iMac übertragen und die Signale erneut erfasst. Folgendes habe ich am Ende gesehen:
Der offensichtliche Unterschied besteht darin, dass das "Serial In" -Signal zu Beginn des Programmiervorgangs nicht logisch hoch wird. Dies ist obligatorisch, da das PICAXE-Programmierprotokoll so funktioniert (oder zumindest so). Sie müssen die TX-Leitung über RS232 aktivieren, wodurch die PICAXE in einen Modus versetzt wird, in dem sie eine Rechteckwelle sendet, gefolgt von Bits, die den Chip-Typ identifizieren.
Aus der Erfassung des Logikanalysators geht ziemlich klar hervor, dass der CH340G-Treiber unter OSX seinen TX-Pin nicht aktivieren darf, die Windows-Version jedoch. Bei dem Versuch, so viele Informationen wie möglich zu sammeln, damit ich WCH bitten kann, mir bei diesem Problem zu helfen, versuche ich zu verstehen, wie es überhaupt möglich ist, TX überhaupt zu behaupten . In der Windows-Welt glaube ich, dass alles als WIN32API-Aufruf endet. Ich habe die FTDI-Treiberdokumentation nur als Referenzrahmen betrachtet und sehe, dass sie beispielsweise Funktionen zum Festlegen des Status von DTR und RTS enthält, jedoch keine Möglichkeit zum Festlegen des TX-Status. Auf der Windows-API-Seite schreiben Sie Daten aus TX, indem Sie WriteFile aufrufen. Ich kenne keinen Weg, mit dem Sie einfach "TX niedrig halten" oder "TX hoch halten" sagen können.
Kann jemand erklären, wie dies unter Windows oder OSX erreicht werden kann, damit ich meine Untersuchung und mein Debugging fortsetzen kann? Es muss eine Möglichkeit geben, die ich vermisse, oder einen Beweis dafür, dass im WCH-Treiber wirklich etwas fehlt. Immerhin habe ich auch das Programmierkabel PICAXE AXE027 und es kann die Chips programmieren, wenn es unter OSX läuft. Wenn Sie wissen, welche Funktionen unter Windows und / oder OSX verwendet werden, um eine Steuerung der Sendeleitung auf Logikebene zu erreichen, wäre dies ebenfalls äußerst hilfreich!
Ich wusste nichts über die Pausenfunktion . Es scheint, dass dies das sein könnte, was dem WCH-Treiber unter OSX fehlt.
Um herauszufinden, wie dieser Chip funktioniert, habe ich Ubuntu 16.04 LTS geladen, in das der WCH-Treiber integriert ist (zumindest glaube ich, dass er von WCH stammt). Ich habe das Programmiertool unter Ubuntu ausgeführt und es funktioniert auch nicht. Die WCH-Quelle wird aufgrund des Unterschieds in der Kernel-Version nicht unter 16.04 kompiliert. Ich habe versucht, die Version zu laden, die ich am 12.04 erstellt habe, aber sie wird nicht geladen. Ich kann nicht unter 12.04 testen, da Chrome unter diesem Betriebssystem nicht mehr unterstützt wird.