In the "STMicroelectronics Acquires Atollic" thread, Laurent D wrote:
You can expect better integration and more seamless ecosystem in 2018.
To which I replied:
And can we also expect better STM32 documentation and more responsiveness on our questions here, or are you throwing all the money on the cuboids and ecosystems?
This sounds like as if I complain of the work of Amel, Khouloud, Imen, Nesrine and others from the Tunis crew whom we see here daily. This was certainly not what I wanted to say.
While they are said to be webmasters, in fact they do provide the basic technical support for STM32 on the daily basis, and they do that very well. Of course, it would be foolish to expect that they are experts on all aspects of every STM32 model, of all the IPs in them, all the hardware details, and all the related software and libraries and stuff. So it is just natural that when a question comes up which can't be answered that easily, they consult others within ST, probably through some established internal channels; and that that may take some time. Also, the energy and time (read: cost) to answer some questions is simply too high - understandably then those questions may remain unanswered, or would need to be submitted through different channels than on a public web/forum.
Our webmasters can hardly influence these factors, even if they know that some of the questions are recurring, and answering them publicly would serve several users also in the future.
However, there are now good times for semiconductor sales, ST is doing very well, and their microcontrollers division is a major part of this success. The purchase of Atollic is undoubtedly result of this conjuncture, an investment to the future. So, apparently, there's some money available to be spent on "integration and ecosystems". And I just wanted to point out, that there is more to "integration and ecosystems" than toolchains, libraries and configuration gadgets.
Microcontroller ecosystem *starts* with documentation - datasheets, manuals of all kinds - which has to be firm and solid, so that other parts of ecosystem can build on it. This is not quite the case of STM32 documentation so far. I understand that it has been conceived in a hurry, similarly as the chips being thrown together from parts of various origin; but now it's perhaps time to get back to it and clean it up thoroughly. The Reference Manuals leave a lot to be desired in conciseness, completeness, especially of the more complex IPs' chapters. There was a nice starting effort in adding the "integration/interconnections" chapter, but that's usually quite incomplete, and it has not been added into the older RMs. There's a weak link to the ARM documents, and the bolierplate ARM manual "converted" to "Programming Manual" is insufficient and poorly customized. Some datasheets may benefit from adding tables like the FMC/FSMC pins in some of them. Some promising appnotes of the basic description character (e.g. the 'F1 DMA which supposedly should apply also to 'F0/'L0/'L4, the "migration between any family" and others) were left abandoned. There is a bunch of other minor issues throughout. Complaints/comments from the users through the forum or other channels usually result in minor corrections; however, some of the documents would need thorough review or maybe even rewrite. This costs money.
Then there are the basic examples, hardware and software. Hardware is excellent - the three lines of boards amended by the addons, they are without any doubt part of where the success came from. But software examples lack far behind. There are one or two dozens of IPs in STM32s, and all of them are relatively complex; some of them interact mutually (e.g. timers and ADC, RCC and almost everything, DMA and almost everything, etc.). The venerable 8051 had two timers, one UART, and came with perhaps two dozens of application notes with accompanying software. Its complexity was roughly similar to complexity of *any* IP in STM32; so I'd expect hundreds of examples and application notes for each STM32. An order of magnitude more than it is now. And they should be again written clearly, documented concisely. Even if based on any library, they should be written with portability in mind, not only across families, but even within one single chip (e.g. easily reconfigurable pins); and best written clearly enough so that they could be ported out of the library into any environment the user may have. This is not the case now - even Cube-based examples can't be easily modified using the tool provided (CubeMX). Don't forget, that the single most powerful programming tool the embedded programmer has is copy-paste. A great source of application notes are people from "outside" who use the chips in real world applications - consultants, or maybe even some of the customers - but then some inhouse work has to be applied to have the rough edges removed. FAEs and other support engineers may contribute, provided they have time allotted for this. But still, this all costs money.
Then come the toolchains, but spending on those were decided already.
Then comes support. I always worked for garage-scale companies so I am used to get along with the publicly available information, don't expect VIP treatment. For me, fora are bonus and manufacturer's presence is a gift. However, as the chips' complexity rises, the chance for an unforeseen combination of circumstances leading to surprising or out-of-documented behaviour increases, IMO faster than linearly. That's why I believe that the forum with hundreds of users exploring millions of various paths may be part of a feedback which may be valuable also for the manufacturer. Besides, a vivid and responsive forum may attract clients like me, of the garage scale, not representing significant purchase power individually, but potentially significant as a mass. But that won't happen without the users seeing real interest from the manufacturer's side. And this won't come with only throwing a handful of people to handle the everyday requests. This requires to handle the more intricate questions - after careful prefiltering - directly by those at the source of the information. I don't say this never happened - but unfortunately doesn't appear to be the norm. Of course that means that those who can handle these questions are tasked with handling these questions and have allocated work time to handle these questions - it's not enough just to wave hands and say "oh they can do that in some spare time". By "not waving hand" I mean also some serious managerial work to get this happen. And all this costs money.
So, my question is, whether, after the seven mega being spent to one of the issues, is there some money left also for the other activities.
Unfortunately, nothing from what I've said above is sexy, nothing promises quick rewards, and seldom managers or purchasers of client companies are interested in these very technical details. However, they are important in the long run in establishment of a solid microcontroller family. ST is said to be a leader in the 32-bit microcontrollers these days - I leave the bending of statistics to the managers, but undoubtedly the STM32s are now one of the most recognized microcontrollers. Leadership comes with responsibility, so ST should lead not only in sales but also in pursuing good practices and showing proper example for the coming generation of developers.