The supported tool chains has changed over time, but originally, and more generally, KEIL and IAR are used by commercial entities creating robust embedded products. GHS (GREENHILLS) by those in the MIC.
There's been a shift in recent years to GNU/GCC and Eclipse based tools, but I'm honestly not sure how well tested and supported they are, or who ultimately "owns" responsibility for the testing / validation.
Examples are just that, they aren't supposed to be top-shelf, production ready, but simply a demonstration that something works as might be expected, and that you and your design team need to adequately test and polish them to your own ends, and to meet your own companies QA standards.
I've certainly complained over the years about the quality and testing of the examples, and the fact that a lot of people can only cut-n-paste code, so that errors and flaws in them just get duplicates everywhere, and contaminates everything. A bit like Microsoft's NT DDK's circa 2000, which can be attributed to a lot of Blue Screens (BSOD), and issue with multi-core SMP systems, etc.
Assume only cursory testing is done.
Assume it is only done with specific ST boards/hardware combinations.
Assume very little "Dog Fooding" is done, developers might have their own tool/method preferences.
Assume CubeMX and CubeIDE have their own issues, and integration conflicts.
Assume the example developers are of average competency in SW, and not necessarily spanning SW and HW, IC Design, QA or Validation.
Assume they were coded by Interns, that's neither good nor bad, but some people with CS degrees are less competent than the computer smart kids in high-school.
#TeamKEIL
