Müssen Sie normalerweise ein USB-Kommunikationsprotokoll einprogrammieren?

Ich habe eine USB-Kommunikation zwischen einem Mikrocontroller, den ich habe, und einem VB.Net-Skript eingerichtet. Ich bin einigermaßen vertraut mit der Funktionsweise des USB-Protokolls.

Meine Frage ist: Muss ich Startframes, Token und Handshaking programmieren, oder wird das alles von der Gerätehardware erledigt? Ich sehe im vb-Wiki von Microsoft, dass die Methode serialport.Readline einen Puffer bis zum ersten neuen Zeilenzeichen liest, und für mich sieht das so aus, als würde es mehr tun, als das USB-Protokoll zulässt. Sie sollten nicht in der Lage sein, kontinuierlich Daten an den Port zu streamen, sie sollten diskret in Frames gesendet werden.

Danke im Voraus.

Beachten Sie, dass Sie ziemlich oft an Frames denken müssen, wenn Sie USB auf dem Mikrocontroller programmieren . Die einfacheren abstrahieren Ihnen dies auch mit einem separaten seriellen USB-Chip, aber fortgeschrittenere lassen Sie es selbst tun, wenn Sie zB eine USB-Tastatur herstellen möchten.
Ich bin verwirrt :-( Ein Mikrocontroller ist ein physisches Gerät mit einer elektrischen Schnittstelle (in diesem Fall USB). Ein VB.net-Skript ist eine Textdatei. Wie können Sie möglicherweise die "Kommunikation" zwischen einem Gerät und einer Textdatei einstellen? Vergessen Sie nicht etwas zu spezifizieren?Wie zum Beispiel mit welchem ​​Host Ihr Kabel verbunden ist?Was läuft auf der Host-Seite?
Eine bessere Art, meine Frage zu formulieren, wäre, dass ich die USB-Kommunikation zwischen meinem Mikrocontroller und meinem PC über ein VB.Net-Skript eingerichtet habe . Ich wollte die Methode, mit der ich kommuniziere, einbeziehen, weil sie für die Frage relevant war. @Ale..chenski

Antworten (4)

Wie jeder Protokollstapel enthält USB Komponenten, die verschiedene Schichten darstellen. High-Level-Treiber und -Bibliotheken bieten Funktionen höherer Schichten auf niedrigeren Schichten und abstrahieren diese niedrigeren Schichten effektiv und außer Sichtweite.

Im Fall von USB gibt es eine Reihe sogenannter Geräteklassen, die standardisierte Schnittstellen auf USB bieten, mit einem koordinierten Protokoll auf der Hostseite (implementiert durch einen Treiber oder einen Stapel von Treibern) und auf der Peripherieseite ( implementiert durch Firmware oder Treiber). Beispiele für diese Geräteklassen sind HID-Geräte wie Tastaturen/Mäuse, Massenspeichergeräte wie Flash-Laufwerke, Bildspeicherung mit PTP/MTP und so weiter. Diese abstrahieren das USB-Protokoll - zum Beispiel sieht der FAT-Dateisystemtreiber, der zum Mounten eines Flash-Laufwerks verwendet wird, ein Blockspeichergerät und muss sich dank der USB-Treiber weiter unten im Stapel keine Gedanken über USB-Framing, Paketierung usw. machen.

In Ihrem Fall ist die relevante Klasse USB CDC (Communications Device Class) . Die CDC-Treiber bieten Benutzerprogrammen auf Ihrem Computer einen seriellen Anschluss, der einen Datenstrom lesen und schreiben kann. In der Zwischenzeit erledigt der CDC-Treiber die Arbeit, einen Strom serieller Bytes und Steuersignale in USB-Pakete umzuwandeln, und er erhält Hilfe von den zugrunde liegenden USB-Treibern im Stack für noch niedrigere Aufgaben wie das Einrichten von Pipes zu Endpunkten.

Da die Spezifikation standardisiert ist, profitieren Sie davon, dass Ihre Anwendung auf USB CDC funktionieren sollte, unabhängig davon, von welchem ​​Anbieter Ihr CDC-kompatibles Gerät stammt (solange sie der Spezifikation entsprechen), da die Treiber Ihres Systems wahrscheinlich entsprechend implementiert sind Spezifikation 1 .

In der Zwischenzeit kann Ihre Anwendung die serielle Schnittstelle verwenden, ohne sich Gedanken darüber machen zu müssen, welche physische Hardware ihr zugrunde liegt. Es könnte seriell über USB sein, es könnte ein neunpoliger serieller D-Sub-Anschluss sein, der mit einem UART auf dem IO-Controller Ihres Motherboards implementiert ist, es könnte ein virtueller serieller Anschluss unter Linux sein, oder es könnte vielleicht eine serielle Verbindung oben sein von TCP/IP.

1 oder mehr lose, um Spielraum für Geräte zu geben, die möglicherweise nicht genau der Spezifikation entsprechen.

Ich glaube, ich habe es jetzt verstanden, ich war davon ausgegangen, dass ich mich beim Lesen/Schreiben zumindest an ein Protokollformat halten müsste. Ich bin Elektroingenieur, also bin ich es nicht gewohnt, beim Programmieren (normalerweise in C) die untere Ebene zu ignorieren. Danke für die Hilfe.
@Jaywalk: Tatsächlich ist "bis zum Zeilenumbruch lesen" nicht Teil der Abstraktion der seriellen Schnittstelle. Die Operationen der seriellen Schnittstelle, die Sie vom USB-Protokollstapel bis zum CDC und den entsprechenden Treibern im Computer erhalten, geben Ihnen die Kontrolle über Dinge wie FIFO-Puffergröße, Gesamtzeitüberschreitung, Zeitüberschreitung zwischen Zeichen usw. ReadLine ist etwas, das die Bibliothek enthält /framework fügt oben hinzu und geht dabei viele Kompromisse ein (z. B. die Konvertierung von Bytes in Zeichen – haben Sie sich an die Codierung erinnert – und nicht wirklich zu wissen, welche Timeouts konfiguriert werden müssen, um die Latenz zu minimieren)
Wenn Sie sich also der Operationen auf Profilebene bewusst sind, können Sie definitiv ein besseres maßgeschneidertes Protokoll erstellen (zum Beispiel wird das Längenpräfix mit viel geringerer Latenz ausgeführt als die Beendigung durch Zeilenumbrüche oder NULs oder andere Steuerzeichen), denn wenn Sie die Länge lesen und Wenn Sie einen Lesevorgang mit fester Größe an den seriellen Anschluss ausgeben, wird ein Befehl über den USB-Bus an Ihr Gerät gesendet, um "den Empfangspuffer sofort weiterzuleiten, wenn diese vielen Bytes verfügbar sind" ... Sie sind nicht auf eine Lücke zwischen den Zeichen angewiesen in der Übertragung zu einem Timeout führen.
Insbesondere die Funktion zum Lesen bis zum Zeilenumbruch ist Teil der Abstraktion für Endgeräte. Dies waren ursprünglich Konsolendienste, die von Mainframes für Schreibmaschinen bereitgestellt wurden, und die menschliche Interaktion mit Schreibmaschinen ist zeilenorientiert. Diese Norm wurde später von Hardware-Ingenieuren verwendet, um Schnittstellen für Geräte wie Modems zu implementieren, die leitungsorientierte AT-Befehle verwenden, weil es für einen Hardware-Ingenieur einfacher war, so zu denken, als komplizierte Frame-orientierte Protokolle wie TCP/IP zu implementieren. .
... heute gibt es immer noch viele seriell orientierte Geräte, die die alten Befehle im AT-Stil verwenden, auch wenn sich ihre Transportschicht weiterentwickelt hat. Die Read-Line-Funktionalität ist hauptsächlich als Annehmlichkeit für Hardware- und Software-Entwickler da. Eine Menge Hardware befasst sich tatsächlich nicht direkt mit USB-Frames, sondern gibt serielle UART-Streams an etwas wie einen FTDI- oder einen CH340-Chip aus, sodass das ganze USB-Paket-Zeug nur Black Boxes für Hardware- und Softwareentwickler sind.
@slebetman ... und interessanterweise ATwerden Befehle verwendet, weil das Bitmuster für AT praktische Bitraten-unabhängige Eigenschaften hat , die es Geräten ermöglichen, sich automatisch darauf zu synchronisieren.

Es steckt bereits im Namen der Funktion: serialport.Readline. Diese Funktion arbeitet an seriellen Ports, nicht an Raw-USB-Endpunkten. Ihr Mikrocontroller "gibt vor", eine serielle Schnittstelle zu sein, die über USB an Ihren Computer angeschlossen ist. Ein serieller Port-Treiber auf Ihrem System kümmert sich um die Konvertierung der Daten aus Ihrem Programm in USB-Pakete (und umgekehrt).

Auf Ihrem Computer befindet sich mehr Software als nur Ihr eigenes Programm. Das Betriebssystem erledigt eine Menge Dinge für Sie.

Wenn Sie Ihren eigenen Treiber schreiben möchten, können Sie das natürlich tun, aber es ist gelinde gesagt ziemlich schwierig. Solange die serielle Kommunikation ausreicht, müssen Sie keine schreiben. Wenn Sie jedoch Ihre eigenen benutzerdefinierten USB-Endpunkte erstellen möchten, müssen Sie einen Treiber dafür schreiben.

Ich werde nicht versuchen, das Rad neu zu erfinden, ich habe nur nicht verstanden, wie es auf der unteren Ebene funktioniert. Angesichts der Tatsache, dass es eine serielle Schnittstelle emuliert, sind die Serialport-Methoden viel sinnvoller. Danke für die Hilfe.

Wenn Sie einen seriellen USB-Anschluss haben, dann ist es für Ihr Programm ein serieller Anschluss.

Und Sie müssen nicht wissen oder sich darum kümmern, ob es sich um einen seriellen Standardanschluss, einen seriellen USB-Anschluss, einen über LAN erweiterten virtuellen seriellen Anschluss oder etwas anderes handelt, solange Ihr Programm einen seriellen Anschluss erkennt.

Danke für die Info und so werde ich vorgehen. Ich war so in die Funktionsweise des USB-Protokolls verstrickt, dass ich nicht bemerkte, dass es möglicherweise abstrahiert wurde.

Meine Frage ist: Muss ich Startframes, Token und Handshaking programmieren, oder wird das alles von der Gerätehardware erledigt?

Ok, lassen Sie mich versuchen, ein umfassendes Bild dessen zu zeichnen, wonach Sie fragen, und zwar auf eine von oben nach unten gerichtete Weise:

  1. Ihr Skript ruft den USB-Treiberstapel auf;
  2. Der USB-Treiber legt eine verknüpfte Liste von Datenstrukturen im PC-Speicher fest, verschiedene "Ring"- und "Transaktionspuffer", je nach Anforderung aus dem Skript;
  3. Der USB-Treiber lädt dann die Startadresse für die Struktur und "klingelt" ein "Türklingelregister" in der USB-Host-Controller-Hardware.
  4. USB-Host-Controller-HARDWARE verwendet DMA (Direct Memory Access), um selbstständig durch die verknüpfte Liste von Strukturen zu gehen;
  5. Die HC-Hardware (Host-Controller) interpretiert die eingehenden Datenstrukturen und sendet Sequenzen von Rohdaten an USB PHY - Physical Layer Translator. Host-HW folgt USB-Protokollen per SIE – Serial Interface Engine (sendet geeignete Tokens und wartet/wertet Busantworten (Handshakes) aus, sendet und empfängt Datenpakete an/von PHY) und berechnet/verifiziert CRC.
  6. PHY ordnet parallele Daten in serielle an, hängt SYNC und EOP an Tokens an und führt eine Datencodierung für den richtigen Ausgleich des Datenumschaltens durch;
  7. Die Host-Hardware generiert kontinuierlich Frame-Tokens an aktivierten Ports, und der SW-Stack überwacht das Frame-Timing und plant Transaktionspakete gemäß den Busregeln.
  8. Geräte implementieren das USB-Protokoll in einer ähnlichen Form von SIE, empfangen/analysieren Pakete, entschlüsseln Adressen/Endpunkte und reagieren ordnungsgemäß und zeitnah.

Mit einer seltenen Ausnahme des Low-Speed-Protokolls (wie Maus/Tastatur, wo es einigen Enthusiasten gelang, USB SIE und PHY auf bit-banging-Weise locker zu implementieren), implementieren alle Mikroprozessoren mit USB-Funktionalität alle wichtigen Protokollfunktionen in Hardware.

Also, um diese direkte Frage zu beantworten, nein, Sie programmieren nicht den Start von Frames und bestimmten Token oder warten auf Handshakes, es wird alles in Hardware unter der Kontrolle des USB-Treiberstapels erledigt.

Müssen Sie normalerweise ein USB-Kommunikationsprotokoll einprogrammieren?
AntwortenHierDatenschutz-Bestimmungen1y, 0v