Closed jmgurney closed 2 years ago
Hi @jmgurney,
Thank you for having reported this point. Actually, version 2.11.0 of the USB Device library has just been released, which addresses your point, as you can see here.
You can get it from the stm32_mw_usb_device repo and use its content to overwrite the same files in your STM32CubeL1 firmware package, as this version is fully compatible with older ones.
Unfortunately, there is no plan in the near future to integrate this version into the STM32CubeL1 firmware. We will notify you, should there be any update. Please allow me to close this issue. Thank you for your comprehension.
With regards,
Please keep this issue open until the firmware package has been updated. The reason I want this to remain open is so that other people who encounter this issue do not have to spend as long trying to figure out what is wrong with their devices.
I do understand that you likely want to keep the number of issues that are open low on your package, but IMO, that should just encourage your management to update and properly maintain the firmware for the micro controllers that you sell, and claim are standards compliant.
P.S. Because of this issue and also this one: https://github.com/STMicroelectronics/STM32CubeL1/issues/10 , I have decided to not use the device profile code that ST releases. And that you do not have a plan to integrate this fixed code into the firmware package reiterates that this is a good choice. ST needs to implement better control management, such as either not including the USB middleware code in the various firmware packages, using submodules or subtree to integrate them, and update them more frequently. If it is as you say, a simple matter of copying over the files, then it should be issue to change how code is released, so that people get these updates.
It'd also be good to have an announcement list that talks about required changes that ST has made to make their code standards compliant so people who use the code can more quickly integrate these changes so that devices are more likely to be standards compliant.
Hi @jmgurney,
I can understand you point. However, even closed, the issue can still appear in search results. Please allow me to close it. It can always be reopened shall there be any update. Thank you for your comprehension.
With regards,
Like F1, it appears that L1's HID classes are not standards compliant despite being claimed to be:
for more info, see: https://github.com/STMicroelectronics/STM32CubeF1/issues/41
https://github.com/STMicroelectronics/STM32CubeL1/blob/master/Middlewares/ST/STM32_USB_Device_Library/Class/HID/Src/usbd_hid.c#L446