For me, it was a nice jump from AVR to STM32. Not without hickups, though. But only one major hickup!
The biggest issue I see is lack of tutorials and information about minimal no-bullshit development - similar way
everyone works on AVR (not counting Arduino) or PIC. Additionally, there is a lot of noise over the trend-tool-and-framework-of-year development style. It has changed several times during my STM32 career, and no one remembers the older ones! So everyone has relearned their tools. I saw this from the start and never looked at these IDEs.
I had really big issues when starting, due to a broken linker script I found online, and it took fairly long to solve this. But everything else went very smoothly, no problems with tools. Compared to an ever-changing IDE environment (not even talking about the "trend framework of the year"), the great thing in make/gcc/ld workflow is that:
1) It's been the same for decades, and will be for unforeseeable future
2) It's the backend in those IDE-of-the-year kludges anyway, so knowing it directly is
the skill.
I wouldn't call this fragmented. I see this as the opposite of fragmented. Of course, a nice click-and-point application may give you a simplistic, warm fuzzy feeling, but really, googling for exact instructions for some exact piece of GUI software, where to click to configure memory regions or something like that, when you have a standard way available, expressed textually and processed by your actual tools directly? I
think we coders could work out without the sugarcoating. At least for me, it's not an issue.
STM32 documentation totally sucks sometimes, but the chips are fairly innovative and having something orders of magnitude more capable than an AVR gives you a nice feeling to compensate for the headscratching. If you do AVR-complexity things on STM32, it's not difficult. But if you do some fancy thing you wasn't even able to
dream about with AVR, you of course need some heavy reference manual reading and headscratching. This is often about combining the peripherals to work together, without CPU, without interrupts, to produce complex interactions, using peripheral-to-peripheral trigger signals, DMA channels...
One thing to be aware of is that when you have an AVR problem, you quickly find out the answer by googling. Whether it's a specific hardware design problem, a very low level software problem, anything.
When I started, really the only thing you could find out by googling any STM32 issue is that:
A lot of people have proudly bought a devboard and have succesfully copy-pasted 100 lines of bloat library code to blink an LED! Hats off to them, but this isn't helping, and no one was actually doing anything on these chips.
... now, this has finally changed
, and you will find actual results of someone actually doing something, and hence, can find some help as well. But it still isn't so straightforward as it is on AVR or PIC. Because both the ARM and the ST guys fucked up the software side by creating too complex, too difficult to use abstraction layers, so the only way to program using these layers was to copy-paste code from Stack Overflow, and then they needed to build code autogeneration tools, and then one of the abstraction layers most people used is now obsolete and not recommended anymore, and then there are different options, and the end result is, the community is totally fragmented. But you don't need to care. Use none of these frameworks/layers and you'll be fine. Do it like you do on AVR.
Many
are actually writing the code sanely, exactly the same way they did on AVR, but these people tend not to need much help, hence they won't post questions and their code won't show up.
When I started with STM32, I was a bit horrified about the fact
there is no help available, but I took the bullet and haven't regretted a bit. I have grown to rely on my own skills more, and trust I can solve any problem. At the same time, I have learned the basic gnu tools properly. The thing is, you are using these tools
anyway, either directly or indirectly. The indirect way is changing all the time. The direct way is a skill you won't ever lose.