STM VCP USB_OCUPADO?

Estoy usando el firmware STM32 VCP y estoy enviando datos a la aplicación de mi PC

Si no abrí mi puerto serial en la PC, y mi firmware continúa enviando los datos, causará que ocurra USB_BUSY (creo que el búfer de transmisión del firmware está lleno y está esperando que el lado de la PC reciba datos)

cuando abro el puerto serie en la aplicación de mi PC durante USB_BUSY, ¡hará que la PC se cuelgue!

¿Puedo saber cómo puedo manejar el estado USB_BUSY en mi firmware? ¿Como puedó resolver esté problema?

Díganos cómo está conectado su sistema. El VCP de STM32 necesita una conexión USB y USART, ¿cómo los conecta?
no uso USART, elimino el componente USART y envío directamente los datos al punto final USB
Umm, quiere decir que su dispositivo no es un traductor USART->USB. ¿Cuál es tu interfaz en PC? RS232 Hiperterminal?
¿Funciona ahora?
@diverger publiqué mi respuesta a continuación

Respuestas (2)

El lado de mi PC es USB, emular como VCP

He logrado resolver el problema pero no es una buena solución...

Agregué 2 cosas:

  1. un protocolo de comunicación
  2. limpiando el búfer tx para vaciarlo

Agregué un nuevo protocolo que es el comando START y STOP, necesito que mi PC envíe un comando STAT a mi firmware, antes de que comience a enviar datos a mi PC

Siempre que esté en modo USB_BUSY, enviaré un búfer vacío para permitir que el firmware de VCP active una interrupción, y esto borrará mi USB_BUSY

Acabo de agregar esta línea de código solamente

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

¡Me encantaría saber si alguien tiene una mejor solución!

¡¡¡ACTUALIZAR!!!

¡Finalmente resolví este problema, reemplazando todo el controlador STM32 HAL para USB CDC de regreso a la biblioteca de periféricos estándar para USB CDC!

y no hay más problema con eso! Me encuentro con muchos problemas al usar el controlador HAL de STM32, ¡tiene muchos errores! Si tiene algún problema, intente volver a la biblioteca de periféricos estándar.

Sí, agregar control de flujo es mejor. También puede intentar cambiar "APP_RX_DATA_SIZE" en usbd_conf.h. Y varias otras macros.
@diverger ¡sí! lo intenté pero no hubo muchos cambios, supongo que una vez que se activa el USB OCUPADO, el host no pudo enviar algún comando para solicitar el descriptor del firmware (esa es la razón por la que se bloquea al abrir el puerto), según tengo entendido al abrir el puerto serie , hay algún protocolo USB que el host necesita para comunicarse con el dispositivo para solicitar algún descriptor (información del puerto) e información del punto final, etc.
Si no abre el puerto serie en la PC, su controlador en el lado de la PC no recibirá los datos, por lo que su dispositivo pronto estará ocupado. Pero cuando abre su serie, su controlador en la PC puede intentar enviar algún comando de configuración a su dispositivo, pero su dispositivo está ocupado enviando ahora, por lo que la PC se bloquea ...
@diverger sí, ¡tienes razón! y una cosa más que no estoy seguro, ¿es que el USB no es bidireccional? por cada cuadro de 1 ms que programe Windows, solo podría enviarse o recibirse, ¿verdad? no pueden ser los dos? ¿tengo razón>?
USB es un protocolo bidireccional de hecho. Pero es un protocolo basado en un mecanismo maestro-esclavo. Toda la actividad de comunicación es emitida por el maestro, el esclavo solo puede responder. Entonces, aquí es donde está el problema.
@diverger Ya veo! así que no puedo enviar y escribir al mismo tiempo, ¿verdad? si hago eso, el host USB programará mi envío o lectura primero y luego la segunda acción.
Umm, puedes imaginar eso, las líneas USB son D+ D-, los datos están representados por la diferencia de nivel entre ellos, por lo que es básicamente un medio dúplex, en cualquier momento solo puede tener datos en una dirección.
Puede intentar primero abrir el com en su PC y luego enviar datos a la PC. Si su código se basa en el ejemplo de ST, creo que debe leerlo detenidamente, luego puede adaptarlo más a su aplicación. Porque el ejemplo de ST es una estructura USART->USB->USART.

Parece un problema de apretón de manos.

El controlador VCP falsifica su USB a un puerto RS232, cuando abre dicho puerto, es posible que deba configurar la velocidad en baudios, el formato de datos, la paridad, el bit de parada, etc. Por lo tanto, su dispositivo no debe enviar datos a su host cuando el configuración no hecha.

Por lo tanto, si debe usar la clase VCP, su dispositivo debe enviar datos después de que se complete la configuración de com. O puede crear su propio protocolo, incluso su propia clase de USB, pero esto necesita volver a escribir el controlador USB en el lado de la PC.

Estas son las definiciones de clase USB CDC (en las que se basa VPC), pueden brindarle ayuda.

STM VCP USB_OCUPADO?
RespuestasAquíPolítica de privacidad1y, 0v