Tasa de baudios del puerto COM virtual STM32

Estoy usando el firmware STM32 VCP y quiero transmitir datos a mi PC desde la placa de descubrimiento STM32F4. La configuración del puerto COM virtual está bien, las propiedades son las siguientes en el administrador de dispositivos:

Configuraciones de VCP

En inglés: 9600 bit/s, 8 bits de datos, sin paridad, 1 bit de parada, sin control de flujo de hardware. Estoy tratando de recibir caracteres en Realterm con estos parámetros, pero no los obtengo, se parece a lo siguiente:

Captura de pantalla en términos reales

¿Qué podría hacer mal?

EDITAR:

La MCU envía con el siguiente fragmento de código:

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);
  }
}
¿Qué datos estás enviando desde la MCU? ¿Cómo has configurado la visualización de RealTerm? Parece que la PC está recibiendo 0x00 repetidamente.
Edité mi pregunta. La configuración de visualización de RealTerm está en ASCII, convirtiéndolo en formato hexadecimal, da realmente 0x00.
¿Le estás dando algo de retraso entre las transmisiones?
Sí, hay algún retraso entre las transmisiones.
¿Puede mostrar el fragmento de código adjunto?
Por cierto, las propiedades del puerto del administrador de dispositivos siempre son anuladas por el software que abre el puerto.
@EugeneSh. Buen punto, pero parece que eso es lo que él quería, ya que así es como se configura RealTerm.
¡No no no! ¡No implementes un retraso como ese! Probablemente solo esté optimizado.
Agregué el fragmento de código a la pregunta. Sí, pensé, hay un problema con la configuración de RealTerm.
Los bucles no solo son feos, probablemente ni siquiera funcionen.
Sin los bucles, el programa entra en el controlador HardFault, por eso creo que no se optimizarán.
Creo que hay alguna función HAL_Delay incluida con los controladores STM32. Úsalo por favor...
O realizar la transmisión una sola vez
Gracias, ahora estoy usando la función HAL_Delay. Pero desafortunadamente el efecto es el mismo.
Lo probé con una sola transmisión, sigue igual.
Desafortunadamente, no tengo la biblioteca para mirar, pero diferentes fuentes sugieren que las cosas de los CDC tienen muchos errores. ¿Puedes publicar el CDC_Transmit_FScódigo que estás usando en Pastebin para verificarlo?

Respuestas (1)

La CDC_Transmit_FSimplementación tiene errores (al menos en la versión que estoy viendo):

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;
}

Como puede ver, el Buffparámetro nunca se usa en la función. Puede intentar modificar la función, copiando Buff( UserTxBufferFSusando memcpyo lo que sea).

Tenías razón, usando memcpy(UserTxBufferFS, Buf, sizeof(char) * Len);before USBD_CDC_SetTxBuffer(hUsbDevice_0, UserTxBufferFS, Len);, los datos se transmiten y puedo verlos en RealTerm. :)
Guau, eso es excepcionalmente defectuoso para el código de muestra del marco proporcionado por el proveedor. ¿Cómo es posible que pase eso por control de calidad?
@RBerteig: He visto un montón de código de marco proporcionado por el proveedor que estaba lo suficientemente podrido como para dudar de que algún error haya causado algún problema porque el código era simplemente inviable. Parece que la función anterior podría tener una oportunidad de funcionar si Bufpasa a equal UserTxBufferFS.
Probablemente así fue como pasó. Desearía que los proveedores se esforzaran un poco más en la calidad del código y en las pruebas del código de muestra.
Esta pregunta se hizo hace un tiempo, pero pensé en agregar: en el último parche de las bibliotecas de ST, esto se solucionó. Pensé que esto estaba rompiendo mi código, pero resulta que no es un problema. La solución fue tan simple como reemplazarlo UserTxBufferFScon Buf, aparentemente.
Tasa de baudios del puerto COM virtual STM32
RespuestasAquíPolítica de privacidad1y, 0v