Puerto STM32f4 a HAL: paquetes de caída de HID USB

Estoy tratando de transferir un código HID personalizado que funcione desde el periférico estándar a HAL. Estoy enviando dos informes consecutivos en un solo ciclo while. En el código periférico estándar, se llama dos veces a lo siguiente para enviar informes alternativos al host (Arch-linux): 

 uint8_t  USBD_HID_SendReport ( USB_OTG_CORE_HANDLE * pdev ,   uint8_t   * report ,   uint16_t  len ) 
    {       
     if   ( pdev -> dev . device_status ==  USB_OTG_CONFIGURED ) 
       { DCD_EP_Tx ( pdev ,  HID_IN_EP ,  report ,  len ); 
       } 
       return  USBD_OK ; 
     }

Pero, intentando lo mismo con HAL es decir, 

 uint8_t  USBD_HID_SendReport ( USBD_HandleTypeDef * pdev ,   uint8_t   * report ,   uint16_t  len ) 
 { USBD_HID_HandleTypeDef * hhid =   ( USBD_HID_HandleTypeDef *) pdev -> pClassData ; 
   if   ( pdev -> dev_state ==  USBD_STATE_CONFIGURED ) 
   { 
     if ( hhid -> state ==  HID_IDLE ) 
     { hhid -> state =  HID_BUSY ; USBD_LL_Transmit ( pdev , HID_EPIN_ADDR , report , len ); 
     } 
   } 
   return  USBD_OK ; 
 }

conduce a que falten paquetes en el lado del host y no se reciben como informes alternativos.

¿Alguien podría señalar cuál podría ser el problema? ¿Es un problema relacionado con el búfer o algo?

Si observa la implementación de las funciones que presumiblemente está utilizando, son bastante diferentes. En lo que llama el caso HAL, la función no hace nada si se establece un estado ocupado, si va a hacer algo, establece ese estado muy ocupado. Por lo tanto, la segunda llamada no tendrá ningún efecto, a menos que otra cosa (como el host) borre ese estado primero.
Hmm ya veo. ¿Puedes sugerir cómo limpiar el estado?
Eso no suena como una buena idea. Probablemente no debería cambiar esto sin tomarse el tiempo para comprenderlo por completo, en el contexto de las expectativas del host. Puede investigar, quizás con el software de monitoreo USB en el host (o alternando un GPIO y observando en un osciloscopio) para ver con qué frecuencia se reciben informes en ambos casos.
Todavía no puedo entender qué borrará el estado ... :(
Estoy votando para cerrar esta pregunta como fuera de tema porque ha sido abandonada por el autor de la pregunta durante más de dos años en estado indeterminado

Respuestas (1)

Chris te dio el punto de que la segunda llamada no tendrá ningún efecto. En realidad, no necesita cambiar manualmente el estado ocupado. Será actualizado por USB ISR. Por lo tanto, solo necesita sondear el estado hhid-> y esperar hasta que se vuelva inactivo. Sin embargo, no lo haga en USB ISR u otros ISR con prioridad igual o superior a USB. En tal caso, el controlador USB-TX nunca se servirá y su programa quedará bloqueado.

Puerto STM32f4 a HAL: paquetes de caída de HID USB
RespuestasAquíPolítica de privacidad54y, 0v