Low-Level-Details für die serielle Kommunikation zwischen UART eines Mikrocontrollers und PC [geschlossen]

Vieles davon dreht sich um Software, nicht um Hardware. Ich werde einen einfachen Überblick geben, der nicht zu weit führt. (Ich habe fast 1000 Seiten der USB 2.0-Spezifikation gelesen und viele solcher über USB angeschlossenen Geräte verwendet. Ich habe auch einige Hintergrundinformationen zu Windows-Treibern.)

Ich würde es sehr schätzen, wenn mir jemand erklären kann, wie intern Daten mit einzelnen Rx- und Tx-Pins vom Mikro zum PC und umgekehrt fließen. Ich möchte wirklich verstehen, wie es tatsächlich auf Hardwareebene funktioniert. (Ich suche aber keinen Beispielcode)

Es gibt einen Prozess für ein USB-Gerät, um sich selbst über USB aufzulisten. Für das Windows-Betriebssystem finden Sie den Prozess hier: Wie listet der USB-Stack ein Gerät auf? . Diese Webseite gibt Ihnen einen guten Überblick über den Aufzählungsprozess, dem Windows folgt, und einige der Gründe, warum dieser Prozess befolgt wird. Ich werde also nicht versuchen, das zu kopieren, was bereits viel besser gemacht wurde, als ich es hier hätte schreiben können. Lesen Sie diese Seite und verschaffen Sie sich einen Überblick über diesen Prozess.

Ohne auf viele Details einzugehen, kann ein USB-Gerät mehrere Endpunkte haben und sie können von mehreren Typen sein. Das Host-Betriebssystem kümmert sich nicht wirklich darum. Es durchläuft nur einen Prozess der Aufzählung, damit sie gemäß ihren Beschreibungen handeln können. Sie haben also möglicherweise ein zusammengesetztes USB-Gerät, das beispielsweise sowohl als HID als auch als MSD aufgeführt wird.

Für viele Demoboards gibt es einen separaten IC (oder mehrere), der die Schnittstelle zum USB-Host-Betriebssystem bereitstellt. Wenn Sie beispielsweise ein TI MSP430-Demoboard mit einem Sockel für eine Vielzahl von MSP430-DIP-Geräten kaufen, gibt es auch einen separaten USB-Bereich auf dem Board. Dieser Abschnitt enthält eine spezielle MCU (Sie können sie sehen, also schauen Sie einfach), die alle USB-Enumerationsdetails verarbeitet, über die Sie NICHT informiert werden, wenn Sie sie an den USB-Hostcomputer anschließen.

Ein Endpunkt, den diese vorinstallierte MCU auflistet, wird zum Debuggen des MSP430-DIP-Chips verwendet, den Sie der Platine hinzufügen können. Sie erhalten nicht viele Informationen über diesen USB-Endpunkt oder die Befehle und Abfragen, die er verarbeitet. Das liegt daran, dass TI die Debugging-Schnittstelle nicht (öffentlich) dokumentiert. Daher wird diese USB-Endpunktkommunikation von einem auf der USB-Host-Seite angeordneten Treiber plus Software abgewickelt, die auf dieser speziellen MCU auf der Demo-Board-Seite vorinstalliert ist. Dieser Debugging-Endpunkt ermöglicht es spezieller Software und Debugging-Protokollen, die fast immer undokumentiert sind, die Debugging-Teile der JTAG-Schnittstelle (oder ähnlich) zu verwenden, die sich auf Ihrem DIP-MCU im Demoboard befindet. Die Debugging-Software erledigt also ihre Aufgabe, indem sie diesen speziellen "Rückkanal"-USB-Endpunkt verwendet. Sie werden NIEMALS viele Informationen zu diesem bestimmten Endpunkt erhalten, ohne zuerst zu beweisen, dass Sie es wissen müssen, und dann auch Ihr Leben zu unterschreiben. (Manchmal erhalten Sie Informationen zum Herunterladen von Code auf ein Gerät. Sie erhalten also Informationen zuTeil dieser Schnittstelle, manchmal. Im Gegensatz dazu ist auch das ARM-CPU-JTAG-Debugging dokumentiert. Benutzerdefinierte Peripheriegeräte, die von Herstellern zur ARM-CPU hinzugefügt wurden, sind jedoch möglicherweise nicht gut dokumentiert.)

Diese spezielle MCU übernimmt jedoch auch einen anderen Endpunkt für Sie. Dies ist ein virtueller COM-Port (HID)-Endpunkt. Das Host-Betriebssystem richtet also einen virtuellen COM-Port-Treiber ein, der dafür ausgelegt ist, eine "Standard"-COM-Port-Schnittstelle darzustellen, die von Software verwendet werden kann, die auf der Seite des USB-Host-Computers (PC) läuft. Jede Software, die Sie auf diesem PC-Computer schreiben, wird mit diesem Treiber "sprechen", als obes wäre ein "echter" COM-Port. Es ist nicht. Es ist nur Software. Diesem virtualisierten COM-Port auf dem Host-PC ist KEINE Hardware zugeordnet. Es ist schließlich ein "virtueller" COM-Port. Alles, was passiert, ist, dass die Dinge, die Sie mit diesem virtuellen COM-Port tun, in USB-Endpunktkommunikation (ein- und ausgehend) umgewandelt werden. In ähnlicher Weise wird das, was Ihre PC-Software bei der Konfiguration dieses Ports tut, auch an die USB-Handhabungs-Spezial-MCU des Demoboards weitergegeben Dieser virtuelle COM-Port-Endpunkt verbindet sich in kleinen Paketen, die ihm mitteilen, was die PC-Software getan haben soll. Einiges davon wird einfach von der speziellen MCU geschluckt und intern gespeichert, damit sie weiß, was später erwartet wird. Für Daten, die über die TX- und RX-Pins ausgetauscht werden sollen, verhält sich die spezielle MCU dann so, als obEs war ein externes serielles Gerät, das an die TX- und RX-Pins Ihrer DIP-MCU angeschlossen war. (Die spezielle MCU arbeitet mit ihren eigenen Pins zum Ansteuern und Empfangen von Ihren DIP-MCU-Pins.) Diese Informationen werden jedoch für den Austausch zwischen dem Host-PC und dieser speziellen MCU, die die USB-Schnittstelle zum PC handhabt, in USB-Pakete umgewandelt.

Soweit Ihre neu programmierte DIP-MCU das beurteilen kann, spricht sie tatsächlich über TX und RX mit einem seriellen Gerät. Dies geschieht ohne die üblichen RS-232-Spannungsanforderungen und verwendet stattdessen die lokale$V_\text{CC}$Netzteile auf der Platine vorhanden. Aber Ihrer Software ist das egal. Solange die TX- und RX-Pins "scheinen", mit etwas zu sprechen, das die Dinge richtig handhabt, ist alles in Ordnung und Ihre Software "funktioniert" einfach so, wie sie funktionieren soll.

NOTIZ

Die Verwendung von Bitraten (hier oft fälschlicherweise als „Baud“ bezeichnet), die in der PC-seitigen Software mit den üblichen Aufrufen der Konfigurationssoftware konfiguriert wurden, hat KEINEN EINFLUSS auf die USB-Endpunktkommunikation. USB arbeitet mit einem völlig anderen Satz von Kommunikationsmechanismen. Der Host-PC und die spezielle MCU Ihres Demoboards kommunizieren also über USB und die Bitratenkonfigurationen werden unabhängig davon weitergegeben. Es ist dann die Aufgabe der speziellen MCU auf dem Demoboard, sich selbst zu "konfigurieren", so dass sie die richtigen Timing-Details verwendet, um so zu handeln, als ob diese Bitrate ausgewählt worden wäre. Aber nachfolgende Daten, die von der Host-PC-Software an das Demoboard übertragen werden, kommen IMMER einwandfrei und intakt an, unabhängig von der eingestellten Bitrate für die serielle Kommunikation. Damit meine ich, dass es immer gut bei der speziellen MCU ankommt. Jedoch, Die spezielle MCU muss nun die Pins mit einer bestimmten Rate an Ihre DIP-MCU bit-bangen, was sie auch tut. Wenn die Raten nicht korrekt angepasst werden, treten die gleichen Probleme auf, die Sie normalerweise erwarten würden. Diese Probleme treten jedoch nur zwischen der speziellen MCU und Ihrer MCU auf, nicht jedoch zwischen dem Host-PC und der speziellen MCU des Demoboards.