Posted on January 12, 2018 at 19:17I view CubeMX as a rapid prototyping method, ST has their BSP model to suit portability across DISCO, NUCLEO and EVAL boards.
In the more practical sense people aren't selling products which bolt a DISCO board into a box and proclaim 'job done'. There is going to be custom hardware and custom software, and how much of the BSP you use and discard depends a lot on expediency and whether that fits into the existing corporate methods for product development. ie the migration to a new product is likely to look a lot more like the previous product than a disparate paradigm some other manufacturer invented.
In the commercial sense you can't do this when the wind blows in the wrong direction
void Error_Handler(void)
{
while(1);
}
The code as provided has zero accountability for failure, and if you ship it to end customers there are going to be zombies at your door, and a tech support department coming after you with pitchforks and torches. Bosses are generally uninterested about why it is someone else's fault your product sucks. There is a disclaimer in the license which basically states 'you use it, you own it'.
My expectation is that most corporate users would have a handful of people create a proof of concept design, pitch that to management, and then take a much larger group and with more time and specific goals (budget, build cost, sell cost), and refactor the snot out of the code and design.
If you like the BSP, and haven't committed to a specific board or chips, it will likely provide a lot of flexibility. You need to review the BSP examples and the level of abstraction ST is shooting for, and then cherry pick and modify the parts you need, or require specific adaptation to the board and display, etc that you want to use in a final product. You work out the kinks in your design, or test areas of the design where new parts can be plugged into existing working boards before committing into your own.
Writing extensive documentation for the BSP is dull work, and not going to be done by the people you'd want to write it, nor in a way that is super helpful or timely. Be a chameleon, absorb the examples, and create something that reflects what it does in the context of your own use case. Need a new display, find the closest match in terms of signalling or controller, fork the example and plug in the specifics from the datasheets and manuals. Do it incrementally based on your ability and comfort level, testing and verifying as you go.
When you have everything functioning take a step back and take an overview about what it took to make it work, and what parts are extraneous. You might determine that the HAL is too bulky and gets in its own way, and then you'll look at if things can be done more efficiently with the LL.
Other corporate users, where there is legal liability for failure, will have rules about writing every line of code that goes into a product. Others with existing libraries might port those onto the STM32 architecture rather than adapt to ST's models and paradigms.
