2019-12-03 10:13 PM
https://community.st.com/s/feed/0D50X0000BiD5iz
The true challenge for ST of course is to stop experimenting with "communities" and get a decent forum software.
(In case ST would not get it, this post does not show up in the posts list, even if it's tagged "STM32MCUs" it shows up only in the "group" or "community" or whatever that other completely unneeded list is). @brk
JW
#worst_forum_software_ever
2019-12-04 02:17 PM
>>IMHO this improvement of quality of examples and libraries is possible only with users themselves (aka community).
No it is not.
Good examples can and should be created by ST, it takes discipline and the right people. It requires corporate buy-in, and dog-fooding, where the examples and tools build on each other and are thoroughly tested so they can be applied in real-world solutions by others, and you don't waste hours with broken tools, and spread broken code all over everywhere.
I used to create a lot of good/working examples, and I found it to be an almost entirely thankless task. I guess I should have just done you-tube videos, or instagramed my breakfast every morning.
Good support is expensive, yet no one values it.
#ChernobylSizedDumpsterFire
2019-12-04 02:25 PM
I'd recommend this book https://www.amazon.com/Normal-Accidents-Living-High-Risk-Technologies/dp/0691004129
2019-12-04 02:28 PM
>>Think of the Challenger disaster, where almost all deciders knew what was almost sure to come.
Some understood the limits of the technologies, some were over confident in them.
And managers not listening to people who had answers they didn't like.
2019-12-05 01:03 AM
No.
But the free-of-charge, first-contact interface (Cube) is in trouble, as the bow wave of requested features, devices to support, toolchains and OSs to support, and bug fixes is growing continuously bigger.
When you find yourself in a hole, stop digging.
2019-12-05 06:03 AM
More likely it is a project too big to fail, AKA "throw good money after bad". Two options: one, somehow all those layers of code start to work reliably; or two, as a manager I can retire or move to another department before the project collapses of it's own support weight. Outsourcing the design/code development to lowest bidder (anyone remember what happened to DEC/Compaq/HP OpenVMS?) will extend the window of opportunity for the second option, though the consequences to end users (as OpenVMS users learned) is a risk for future goodwill.
For myself I still think ST makes excellent M series controllers and I'll continue to use them. I'm far enough along with my own version of the venerable SPL libraries that I don't have to rely on Cube, the silly pretense of the LL library or anything else ST tries to force onto users. It does force me to go elsewhere for BLE controllers and MEMS sensors, since ST has decided to forego any significant documentation on their offerings in favor of "run the software"
Jack Peacock.