Ist es möglich, einen Host auf stm32 (ohne Hardwareunterstützung) nur mit dem Programmcode zu implementieren, um Daten auf den USB-Stick zu schreiben? [geschlossen]

Ist es möglich, einen Host auf stm32 (ohne Hardwareunterstützung) nur mit dem Programmcode zu implementieren, um Daten auf den USB-Stick zu schreiben? Ich habe im Internet keine Informationen zu diesem Thema gefunden. Es gibt ein Implementierungsgerät, aber keinen Host. Ich studiere die USB-Spezifikation für die Antwort, aber ich verstehe sie immer noch nicht gut.

Es gibt Hunderte von verschiedenen STM32
Meinst du USB-Host? und Sie möchten das ohne spezielle Firmware auf dem STM32 booten?
@EugenSch. Ja, aber ich habe eine, die keine Hardwareunterstützung hat
Was ist "Hardwareunterstützung"?
@Jasen Ja, ich meine USB-Host. Vielleicht mit eingeschränkten Fähigkeiten, da ich nur auf ein USB-Laufwerk schreiben muss.
"Hardware-Unterstützung" wäre der USB-OTG-Peripherieblock (oder zumindest USB-Gerät). Und nein, das ist kein vernünftiges Projekt - besorgen Sie sich einfach einen STM32 mit OTG-Port; Diese Funktion wird in allem bis hin zu den M0s angeboten, einschließlich TQFP-Paketen, mit denen man einfach arbeiten kann. Oder verwenden Sie eine SDCARD im SPI- oder Bit-Bang-Modus selbst auf den primitivsten anstelle von USB.
@MarcusMüller Ich meine, dass die Austauschfunktion bereits auf logischer Ebene und in den Registern im Mikrocontroller vorhanden ist
@ChrisStratton Ich verstehe, dass dies nicht vernünftig ist, weil ich niemanden gesehen habe, der es getan hat. Aber die Antwort auf die Frage "warum?" Wurde nicht gefunden.
Weil Bit-Banging USB an der Spitze des Möglichen steht; und typischerweise hängt die geräteseitige Implementierung davon ab, dass der Host regulär ist, während er Abstriche macht. Ich habe von jemandem gehört, der es an einem Propeller macht, aber das ist ein seltsamer Chip. Letztendlich ist das größte Argument, dass Sie riesige Produktionsmengen herstellen müssten, bevor sich die Mühe lohnt, dies zu versuchen.
@ChrisStratton stimme voll und ganz zu; es wird so gut wie unmöglich sein, mit fahrplan.events.ccc.de/congress/2016/Fahrplan/events/8031.html auch ein volles Dateisystem zu handhaben
Das Dateisystem ist wahrscheinlich überhaupt kein Problem - dieser Teil kann so schmerzhaft langsam wie nötig erledigt werden, es geht wirklich nur darum, den Status zu speichern und weiterzuentwickeln.
@ChrisStratton Nun, wenn Sie Ihre gesamte Firmware anpassen müssen, um das Timing des Busses, den Sie fahren, kaum einzuhalten, wie tauschen Sie dann noch Daten aus? (Meine Wortwahl war unglücklich: Ich meinte nicht das Dateisystem als Datenstruktur, sondern die Tatsache, dass jemand mit den Daten umgehen muss, während er sich noch mit USB befasst)

Antworten (1)

Warum kann die Host-Funktion nicht mit reiner Gerätehardware implementiert werden? Denn der USB ist bezüglich Host und Devices nicht symmetrisch.

Auf der Geräteseite besteht die USB-Funktion darin, das grundlegende USB-Protokoll namens "SIE", Serial Interface Engine, zu unterstützen. Diese Engine beinhaltet die Gerätefähigkeit, Host-Anfragen zu EMPFANGEN, beginnend mit "Standard-Pipe", und richtig zu antworten, indem Daten mit einer ACK-Antwort abgerufen werden, oder Daten gesendet werden und auf Host-ACK gewartet wird, um Transaktionen abzuschließen. Aufgrund von USB-Timing-Beschränkungen (1,7 us Antwortzeit) kann die letzte Phase der Kontrolltransaktion nicht durch Software implementiert werden, und die meisten Teile der SIE-Engines von Geräten sind hardwarecodiert. Andere Funktionen von SIE sind das Akzeptieren der Adresszuweisung und das Akzeptieren/Aktivieren der Konfiguration, was die Aufzählungsphase des USB-Anschlussprotokolls abschließt. Dann unterstützt SIE grundlegende IN/OUT/andere Pipes innerhalb der gleichen Protokolleinschränkungen. Kurz gesagt, die Gerätefunktion besteht darin, zu REAGIEREN.

Aufgrund dieser Hardwarebeschränkungen ist es unmöglich, die Gerätemaschine für Hostfunktionen zu verwenden, hauptsächlich weil die Hostfunktionen den Gerätefunktionen völlig entgegengesetzt sind. Die Busabwicklung folgt sehr unterschiedlichen Zustandsautomaten. Der Host muss periodische Rahmenpakete ERZEUGEN und alle Transaktionen INITIIEREN. Und stellen Sie dann einen reibungslosen Datenstrom bereit, was normalerweise mit Direct Memory Access-Hardware erfolgt. Der Host muss eine Port-Power-Funktion und eine Port-Reset-Funktion bereitstellen, die in Geräteimplementierungen nicht vorhanden sind.

Dies sind die Hauptgründe, warum MCU mit separaten Host-Hardware- und Geräte-Hardware-Controllern konzipiert sind.

Ganz zu schweigen davon, dass ich wirklich begeistert wäre, wenn jemand auch nur auf einer physikalischen Ebene in der Lage wäre, FS USB mit einem billigen STM32 zu bitbangen – es ist nicht so, dass Sie LS verwenden können, um mit einem Massenspeichergerät zu sprechen, oder? Und LS (Device) auf einem Cortex-M zu machen, ist selbst mit viel gutem Willen auf der Host-Seite in Software kaum möglich.
@MarcusMüller, wenn Sie einen externen USB-PHY über UTMI/ULPI haben, könnte es möglich sein, einen FS-Host mit BYTE-Banging zu erstellen, wenn Sie direkten Zugriff auf den UTMI-Port haben. Was man normalerweise nicht hat. Sie können jedoch einen FPGA-Wrapper erstellen. Und ja, es gibt keinen Massenspeicher bei LS-Geschwindigkeiten.
Ja, aber das Hinzufügen eines FPGA, nur damit Sie keine MCU kaufen müssen, die entweder mit UTMI-Zugriff oder tatsächlicher dedizierter Host-Controller-Hardware ausgestattet ist, wäre ... gelinde gesagt ein überraschender Schritt. Ganz zu schweigen von der Tatsache, dass die Menge an bloßer Intelligenz erforderlich ist, um mit einem potenziell umzugehen 2 7 -Gerätebus von gemischten Geräten ist möglicherweise etwas intensiver als das, was ein "dummes" Gerät können muss.