I'm an electrical design guy, dilettante wrt embedded software. 8-bit AVR controllers were a breeze to work with at a bare-metal level.
Now that I'm attempting to acquaint myself with the STM32 environment and the requisite libraries, I'm finding the toolchain and environment a lot more challenging than what I remember from working with AVR.
I'm assuming you are referring to the Arduino family when you say "8-bit AVR controllers"? If yes, they do in fact do a great job at making things somewhat easy for the dabbler, and have many resources available online to peruse for help.
Taking the next step to full-on embedded development (STM32 in this case), as you are finding out, is quite a big leap. Not that it can't be done, but that it really is challenging.
Guess it depends on your background and your familiarity with software development and/or hardware in general.
The Cortex M3 (and any of the other ARMs that offer ETM[2]) is as good if not better than any debugger I've ever used[3], software, hardware, micros, CPLD's, FPGAs. You need to throw a few hundred down for the ULINKpro, but the Segger ST everyone uses I think speaks ETM. Making the jump from Arduino to UL certified production run consumer products with injection molded custom casing holding your 6 layer board has never been easier.
ST even offers documentation on how to use FreeRTOS[4] if you need hard scheduling requirements (though I'd go with Micrim, Wind River, or one of the usual suspects that has already been vetted if you're going to market in, say, the medical device industry).
[1] http://www2.keil.com/coresight/ [2] http://www.ecnmag.com/article/2010/07/debug-code-arm-cortex-... [3] Cincom Smalltalk notwithstanding. [4] http://www.st.com/web/en/catalog/tools/PF260200
As it is, I'm in the same boat as the grandparent comment. I'm moving over to STM32 and I'm loving nearly everything about it. While there are more toolchains and less hand holding the possibilities are much more exciting. All in all, it's a great time to be doing embedded development.
Personally, an article like this, with its main diagram and high level descriptions, would have been enormously useful back when I was just starting to learn the dark arts of computer programming.
If your Point of Sale systems are running some embedded form of Linux, and all HW access is abstracted away from you, then you're probably right.
On the other hand, if you are writing code that deals with external HW signals, performant memory access, ISRs, an RTOS and their many features, etc, then this article serves as a good basic foundation for the "software" side of things. Ie what actually happens when you hit the "build" button in your IDE.
From, a long time embedded software engineer