Baudrate des virtuellen STM32-COM-Ports

Ich verwende die STM32 VCP-Firmware und möchte Daten vom STM32F4 Discovery Board auf meinen PC übertragen. Die Konfiguration des virtuellen COM-Ports ist in Ordnung, die Eigenschaften im Gerätemanager sind folgende:

VCP-Konfigurationen

In Englisch: 9600 Bit/s, 8 Datenbit, keine Parität, 1 Stoppbit, keine Hardware-Flusskontrolle. Ich versuche, Zeichen in Realterm mit diesen Parametern zu empfangen, aber ich bekomme sie nicht, es sieht wie folgt aus:

Realterm-Screenshot

Was könnte ich falsch machen?

BEARBEITEN:

Die MCU sendet mit folgendem Codeschnipsel:

int main(void)
{
  HAL_Init();
  SystemClock_Config();
  MX_GPIO_Init();
  MX_USB_DEVICE_Init();
  uint8_t Buf[] = "test";
  HAL_Delay(1000);
  while (1)
  {
      CDC_Transmit_FS(Buf, 4);
      HAL_Delay(1000);
  }
}
Welche Daten senden Sie von der MCU? Wie haben Sie die Anzeige von RealTerm konfiguriert? Es scheint, dass der PC wiederholt 0x00 empfängt.
Ich habe meine Frage bearbeitet. Die RealTerm-Anzeigekonfiguration ist in ASCII, dreht man sie ins Hex-Format, gibt es wirklich 0x00.
Geben Sie ihm eine Verzögerung zwischen den Übertragungen?
Ja, es gibt eine gewisse Verzögerung zwischen den Übertragungen.
Können Sie das umschließende Code-Snippet zeigen?
Übrigens werden die Porteigenschaften des Gerätemanagers immer von der Software überschrieben, die den Port öffnet.
@EugenSch. Guter Punkt, aber es sieht so aus, als ob er das wollte, denn so ist RealTerm eingerichtet.
Nein nein Nein! Implementieren Sie keine solche Verzögerung! Wahrscheinlich ist es nur wegoptimiert.
Ich habe das Code-Snippet zur Frage hinzugefügt. Ja, dachte ich, es gibt ein Problem mit der Einrichtung von RealTerm.
Die Schleifen sind nicht nur hässlich, sie funktionieren wahrscheinlich nicht einmal.
Ohne die Schleifen geht das Programm in den HardFault-Handler, deshalb denke ich, dass sie nicht optimiert werden.
Ich denke, es gibt eine HAL_Delay-Funktion, die mit STM32-Treibern gebündelt ist. Benutze es bitte...
Oder führen Sie die Übertragung nur einmal durch
Danke, ich verwende jetzt die HAL_Delay-Funktion. Aber leider ist der Effekt derselbe.
Ich habe es mit nur einer Übertragung versucht, immer noch das gleiche.
Leider habe ich die Bibliothek nicht zum Anschauen, aber verschiedene Quellen deuten darauf hin, dass das CDC-Zeug sehr fehlerhaft ist. Können Sie den CDC_Transmit_FSCode, den Sie verwenden, auf Pastebin posten, um ihn zu überprüfen?

Antworten (1)

Die CDC_Transmit_FSImplementierung ist fehlerhaft (zumindest in der Version, die ich mir anschaue):

uint8_t CDC_Transmit_FS(uint8_t* Buf, uint16_t Len)
{
  uint8_t result = USBD_OK;
  /* USER CODE BEGIN 8 */
  USBD_CDC_SetTxBuffer(hUsbDevice_0, UserTxBufferFS, Len);  
  result = USBD_CDC_TransmitPacket(hUsbDevice_0);
  /* USER CODE END 8 */
  return result;
}

Wie Sie sehen können, Buffwird der Parameter nie in der Funktion verwendet. Sie können versuchen, die Funktion zu ändern, indem Sie die Buffin UserTxBufferFS(using memcpyoder was auch immer) kopieren.

Du hattest recht, mit memcpy(UserTxBufferFS, Buf, sizeof(char) * Len);before USBD_CDC_SetTxBuffer(hUsbDevice_0, UserTxBufferFS, Len);werden die Daten übertragen, und ich kann es in RealTerm sehen. :)
Wow, das ist außergewöhnlich fehlerhaft für vom Anbieter bereitgestellten Framework-Beispielcode. Wie ist das möglicherweise durch QC gekommen?
@RBerteig: Ich habe eine Menge vom Anbieter bereitgestellten Framework-Code gesehen, der so faul war, dass ich bezweifle, dass irgendwelche Fehler jemals Probleme verursacht haben, weil der Code einfach nicht funktionsfähig war. Die obige Funktion sieht so aus, als könnte sie funktionieren, wenn sie Bufgleich ist UserTxBufferFS.
So kam es wohl durch. Ich wünschte, die Anbieter würden sich etwas mehr Mühe mit der Codequalität und dem Testen von Beispielcode geben.
Diese Frage wurde vor einiger Zeit gestellt, aber ich dachte, ich würde hinzufügen: Im neuesten Patch der Bibliotheken von ST wurde dies behoben. Ich dachte, das würde meinen Code brechen, aber es stellt sich heraus, dass es kein Problem ist. Die Lösung war anscheinend so einfach wie das Ersetzen UserTxBufferFSdurch Buf.
Baudrate des virtuellen STM32-COM-Ports
AntwortenHierDatenschutz-Bestimmungen1y, 0v