STM32f4 Port zu HAL: USB HID verwirft Pakete

Ich versuche, einen funktionierenden benutzerdefinierten HID-Code vom Standard-Peripheriegerät nach HAL zu portieren. Ich sende zwei aufeinanderfolgende Berichte in einer einzigen while-Schleife. Im Standard-Peripheriecode wird Folgendes zweimal aufgerufen, um alternative Berichte an den Host (Arch-Linux) zu senden: 

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

Aber versuchen Sie das gleiche mit HAL, dh 

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

führt dazu, dass Pakete auf der Hostseite fehlen und nicht als alternative Berichte empfangen werden.

Könnte jemand darauf hinweisen, was das Problem sein könnte? Ist es ein Pufferproblem oder so?

Wenn Sie sich die Implementierung der Funktionen ansehen, die Sie vermutlich verwenden, sind sie ganz anders. In dem Fall, den Sie als HAL-Fall bezeichnen, führt die Funktion nichts aus, wenn ein Besetztzustand festgelegt ist. Wenn etwas ausgeführt wird, wird dieser sehr Besetztzustand festgelegt. Der zweite Aufruf hat also keine Auswirkung, es sei denn, etwas anderes (z. B. der Host) löscht diesen Status zuerst.
Hmm, ich verstehe. Können Sie vorschlagen, wie der Staat geklärt werden kann?
Das klingt nicht nach einer guten Idee. Sie sollten dies wahrscheinlich nicht ändern, ohne sich Zeit zu nehmen, um es im Kontext der Erwartungen des Hosts vollständig zu verstehen. Sie können untersuchen, möglicherweise mit einer USB-Überwachungssoftware auf dem Host (oder einem GPIO umschalten und einen Bereich überwachen), um festzustellen, wie oft in beiden Fällen tatsächlich Berichte empfangen werden.
Immer noch nicht in der Lage herauszufinden, was den Zustand klären wird ... :(
Ich stimme dafür, diese Frage als nicht zum Thema gehörend zu schließen, da sie vom Fragesteller seit über zwei Jahren in unbestimmtem Zustand aufgegeben wurde

Antworten (1)

Chris gab Ihnen den Punkt, dass der zweite Anruf keine Wirkung haben wird. Eigentlich müssen Sie den Besetztzustand nicht manuell ändern. Es wird von USB-ISRs aktualisiert. Sie müssen also nur den hhid-> -Status abfragen und warten, bis er sich im Leerlauf befindet. Tun Sie dies jedoch nicht in USB-ISRs oder anderen ISRs mit einer Priorität, die gleich oder höher als USB ist. In diesem Fall wird das USB-TX-Handle niemals bedient und Ihr Programm wird blockiert.

STM32f4 Port zu HAL: USB HID verwirft Pakete
AntwortenHierDatenschutz-Bestimmungen54y, 0v