STM-VCP USB_BUSY?

Ich verwende STM32 VCP-Firmware und sende Daten an meine PC-Anwendung

Wenn ich meine serielle Schnittstelle im PC nicht geöffnet habe und meine Firmware weiterhin die Daten sendet, wird USB_BUSY ausgelöst (ich denke, der Firmware-Übertragungspuffer ist voll und wartet darauf, dass die PC-Seite Daten empfängt).

Wenn ich die serielle Schnittstelle in meiner PC-Anwendung während des USB_BUSY öffne, wird der PC hängen bleiben!

Darf ich wissen, wie ich den Zustand USB_BUSY in meiner Firmware handhaben kann? wie kann ich dieses Problem lösen?

Bitte teilen Sie uns mit, wie Ihr System angeschlossen ist. Das VCP von STM32 benötigt eine USB- und USART-Verbindung, wie verbinden Sie sie?
Ich verwende kein USART, ich entferne die USART-Komponente und sende die Daten direkt an den USB-Endpunkt
Ähm, Sie meinen, Ihr Gerät ist kein USART-> USB-Übersetzer. Was ist Ihr Frontend in PC? RS232 Hyperterminal?
Funktioniert es jetzt?
@diverger Ich habe meine Antwort unten gepostet

Antworten (2)

Meine PC-Seite ist USB, als VCP emulieren

Ich habe es geschafft, das Problem zu lösen, aber keine gute Lösung, du ...

Ich habe 2 Dinge hinzugefügt:

  1. ein Kommunikationsprotokoll
  2. Löschen des tx-Puffers auf leer

Ich habe ein neues Protokoll hinzugefügt, das START- und STOP-Befehl ist. Ich brauche meine PC-Seite, um einen STAT-Befehl an meine Firmware zu senden, bevor sie beginnt, Daten an meinen PC zu senden

Immer wenn es sich um den USB_BUSY-Modus handelt, sende ich einen leeren Puffer, damit die VCP-Firmware einen Interrupt auslösen kann, und dies löscht mein USB_BUSY

Ich habe nur diese Codezeile hinzugefügt

USBD_LL_DataInStage((USB handler), (endpoint), 0); // 0 = empty buffer

Ich würde gerne wissen, ob jemand eine bessere Lösung hat!

AKTUALISIEREN!!!

Ich habe dieses Problem endlich gelöst, indem ich den gesamten STM32-HAL-Treiber für USB-CDC durch die Standard-Peripheriebibliothek für USB-CDC ersetzt habe!

und es gibt kein problem mehr damit! Ich habe viele Probleme mit dem HAL-Treiber von STM32, er ist sehr fehlerhaft! Wenn Sie damit auf ein Problem stoßen, versuchen Sie, zurück zur Standard-Peripheriebibliothek zu wechseln!

Ja, das Hinzufügen von Flusskontrolle ist besser. Sie können auch versuchen, "APP_RX_DATA_SIZE" in usbd_conf.h zu ändern. Und einige andere Makros.
@diverger jap! Ich habe das versucht, aber es hat sich nicht viel geändert. Ich denke, sobald USB BUSY ausgelöst wird, konnte der Host nach meinem Verständnis beim Öffnen des seriellen Ports keinen Befehl senden, um nach dem Deskriptor von der Firmware zu fragen (deshalb hängt er beim Öffnen des Ports). , gibt es ein USB-Protokoll, das der Host mit dem Gerät kommunizieren muss, um nach einem Deskriptor (Portinformationen) und Endpunktinformationen usw. zu fragen
Wenn Sie die serielle Schnittstelle im PC nicht öffnen, empfängt Ihr Treiber auf der PC-Seite die Daten nicht, sodass Ihr Gerät bald ausgelastet ist. Aber wenn Sie Ihre Seriennummer öffnen, versucht Ihr Treiber auf dem PC möglicherweise, einen Konfigurationsbefehl an Ihr Gerät zu senden, aber Ihr Gerät ist gerade damit beschäftigt, zu senden, also hängt der PC......
@diverger ja, du hast recht! Und noch eine Sache, bei der ich mir nicht sicher bin, ob USB nicht bidirektional ist? Für jeden 1-ms-Frame, den Windows plant, kann es nur entweder senden oder empfangen werden, oder? es kann nicht beides sein? hab ich recht>?
USB ist in der Tat ein bidirektionales Protokoll. Aber es ist ein Protokoll, das auf einem Master-Slave-Mechanismus basiert. Alle Kommunikationsaktivitäten werden vom Master ausgegeben, der Slave kann nur antworten. Hier liegt also das Problem.
@diverger Ich verstehe! Ich kann also nicht gleichzeitig senden und schreiben, oder? Wenn ich das tue, plant der USB-Host entweder mein Senden oder Lesen zuerst und dann die 2. Aktion?
Umm, Sie können sich das vorstellen, die USB-Leitung ist D + D-, die Daten werden durch den Pegelunterschied zwischen ihnen dargestellt, also ist es im Grunde ein Halbduplex, es kann immer nur Daten in eine Richtung haben.
Sie können versuchen, zuerst die com auf Ihrem PC zu öffnen und dann Daten an den PC zu senden. Wenn Ihr Code auf dem Beispiel von ST basiert, sollten Sie sie meiner Meinung nach sorgfältig lesen, dann können Sie ihn besser an Ihre Anwendung anpassen. Weil das Beispiel von ST eine USART->USB->USART-Struktur ist.

Es scheint ein Handshaking-Problem zu sein.

Der VCP-Treiber täuscht Ihren USB an einen RS232-Port vor, wenn Sie einen solchen Port öffnen, muss er möglicherweise die Baudrate, das Datenformat, die Parität, das Stoppbit usw. konfigurieren. Ihr Gerät sollte also keine Daten an Ihren Host senden, wenn dies der Fall ist Konfiguration nicht durchgeführt.

Wenn Sie also die VCP-Klasse verwenden müssen, sollte Ihr Gerät Daten senden, nachdem die COM-Konfiguration abgeschlossen ist. Oder Sie können Ihr eigenes Protokoll erstellen, sogar Ihre eigene USB-Klasse, aber dazu müssen Sie den USB-Treiber auf der PC-Seite neu schreiben.

Dies sind die USB-CDC-Klassendefinitionen (auf denen VPC basiert), die Ihnen möglicherweise helfen können.

STM-VCP USB_BUSY?
AntwortenHierDatenschutz-Bestimmungen1y, 0v