STM32Cube repository on Github

It would be better to get any official updates from the official Git repository as soon as possible rather than sitting and waiting for the new official zip-file complete release. Also I'm ready to contribute my bugfixes and improvements to the HAL sources via pull requests.

We hear your frustration and take all feedback and suggestions into consideration. ST is working to improve the STM32Cube experience for everyone, and make firmware development more collaborative by targetting a similar solution in our future plans.

GitHub, bitbucket and a whole bunch of free repositories.The location of the program code STM32Cube is beneficial for the st. Users themselves will find errors, create their own branches, the administration will need to check the already ready solution - to the place and time of error detection.This is much easier than discussing through a forum where most users sometimes can not formulate their problem.

This would be great. I have found numerous bugs in STM32Cube and the code it creates. I would love to see both STM32Cube and the HAL drivers on github as well where we could submit and discuss pull requests.

What bugs have you found in the USB device library? My company is trying to bring a USB device to market rapidly using STM32Cube, and I've found a bug where the order of the interrupt handlers seems to cause the HAL driver to get stuck in the USB busy state, leaving it unable to send any more IN transfers. I'll create a separate topic for the bug report with my proposed fix, but it would be ideal to move the whole development process to GitHub.

Please note that your request to manage STM32Cube on GitHub is shared internally. So it will be under review.Waiting for a solution that meets your expectation, could you please report the problems and bugs you are facing or any other feedback on our STM32 related forums (if possible in separate discussions)?

This is just a friendly reminder that ST's users would still like to see this.

Is this still being considered internally?

It would be much easier to propose fixes for HAL code as git pull requests than posting them here. Also, I always have bug fixes for the HAL that must be re-applied every time a new version comes out from ST. It would be much easier to pull down new HAL versions with git and merge ST's changes with mine until the fixes are accepted by ST.

I'd vote for more internal code review and testing. A lot of the issues don't need more eyes, just critical ones. There needs to be stronger leadership in the manner this is tested and released. The bug list and tracking needs to be more transparent.

This is embedded, you can't be patching flaws every week like Adobe/Microsoft, it's not a model that works well.

>>This is embedded, you can't be patching flaws every week like Adobe/Microsoft, it's not a model that works well.

I could not agree more. In any S/W development realm it is a huge risk to update any portion of the tool chain.

For example, I updated MX to 4.11 which had a bug that trashed project configuration files.

As far as dog fooding, I would suggest that ST hire a small army of summer interns who can rewrite the example and demo projects to use MX. There seems to be a paucity of examples projects from ST that use it.