Порт STM32f4 для HAL: USB HID отбрасывает пакеты

Я пытаюсь перенести рабочий HID-код со стандартного периферийного устройства на HAL. Я отправляю два последовательных отчета в одном цикле while. В стандартном периферийном коде следующее вызывается дважды для отправки альтернативных отчетов на хост (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 ; 
     } 

Но, пробуя то же самое с HAL, т.е.

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

приводит к отсутствию пакетов на стороне хоста и не принимается в качестве альтернативных отчетов.

Может ли кто-нибудь указать, в чем может быть проблема? Это проблема, связанная с буфером или что-то?

Если вы посмотрите на реализацию функций, которые вы, вероятно, используете, они будут совершенно другими. В том, что вы называете случаем HAL, функция ничего не делает, если установлено состояние занятости, если она собирается что-то делать, она устанавливает это состояние очень занятости. Таким образом, второй вызов не будет иметь никакого эффекта, если что-то еще (например, хост) не очистит это состояние первым.
МММ ясно. Можете ли вы предложить, как очистить государство?
Это не похоже на хорошую идею. Вы, вероятно, не должны изменить это, не занимая время, чтобы понять это полностью, в контексте ожидания хозяина. Вы можете провести расследование, возможно, с помощью программного обеспечения для мониторинга USB на хосте (или же переключить GPIO и наблюдать за областью действия), чтобы выяснить, как часто на самом деле принимаются отчеты в обоих случаях.
До сих пор не в состоянии разобраться, что очистит государство ... :(
Я голосую, чтобы закрыть этот вопрос как не по теме, потому что он был оставлен автором более двух лет в неопределенном состоянии.

Ответы (1)

Крис дал вам понять, что второй звонок не будет иметь никакого эффекта. На самом деле вам не нужно вручную менять состояние занятости. Он будет обновляться через USB ISR. Так что вам просто нужно опросить состояние hhid-> и подождать, пока оно перейдет в режим ожидания. Однако не делайте этого в USB ISR или других ISR с приоритетом, равным или превышающим USB. В этом случае дескриптор USB-TX никогда не будет обслуживаться, и ваша программа будет заблокирована.