I guess my point was that claiming 32bit CPUs are "easier to use" than 8-bit chips is a bit ... misleading
Thanks! I think no one disagrees here; I haven't seen anyone claiming this, so it makes little sense to go against such a strawman any longer.
Of course the super simple 8-bitter is going to be easier to use and understand. It's so much smaller and less complex that it has to be easier.
But by how much? And what's the end result?
If you compare a $3 AVR to a $3 STM32, you'll see the latter has about:
10x larger number of peripherals, each of which has...
about 10x more features, hence complexity; and
then, the core/bus system/memory system as a whole performs about 20-100x faster for computational tasks.
You can use it to do a completely different league of things.
It's inevitable this is going to be
hundreds of times more complex, internally. If the pricing was linear wrt some kind of "capability" index, the cost for the $3 STM32 would be $300. Or the cost for the $3 AVR should be $0.03.
So, people are likely to expect this $3 STM32 to be
hundreds of times more difficult to use.
Now, coupled to the fact that people see cryptic code examples where blinking an LED and reading the ADC takes 500 lines of code (autogenerated or copypasted), while the same on AVR takes 15 lines, this reinforces the assumption. The problem is, it
really takes about the same 15 lines of code to do the same on the said STM32, if done sanely! Actually, everything is surprisingly similar, there just are more features, which can be mostly ignored when not needed, but they give you a slight bit of extra mental overhead anyway.
Now, my point is, a modern typical ARM MCU hides the extra complexity fairly well, behind a sane structure. Some very vendor-specific and odd requirements from the 8-bit world simply disappear, and work out straight out of the box. Having everything clearly memory mapped without strange address space limitations and workaround is a prime example. This sane architecture offsets for the extra complexity elsewhere. The end result is
surprisingly easy to grasp.
Of course, if you have done a lot of work on 8-bitters, you may be expecting the same "rules" of complexity are true on a 32-bit ARM, as well. For example, you seem to be expecting that the Core-coupled memory of STM32F334 is...
you're going to end up using a relatively complex-to-use vendor-specific feature to get the job done.
I can see where you are coming from with this assumption; if there was such an extra memory section on a PIC, it would (very likely) be relatively complex-to-use and at least very vendor-specific. But you are wrong. Said CCM is utterly trivial. Actually, it just works out of the box. It doesn't even need a single enable bit. No configuration. No custom tools, no knowledge of anything vendor specific. The memory address range is given in the manual and it just works there. Put your code to this address range, and it runs fast. Took literally less than 5 minutes for me to do this first time ever, worked on the first compilation. Completely agnostic to the workflow, libraries or compiler.
Of course, if you have never looked at how to use C and/or linker to define in which memory section your code and/or variables go to (or similar in the graphical settings of your IDE of choice), you need to learn that, but it just couldn't be easier, and definitely no vendor-specific anything. I use a custom linker script and my own startup code since it seems most flexible to me and I surely know what I get, but I guess there are easier point/click ways.
On AVR, for example, you can only run instructions from flash, and reading (const) data out of the flash requires specific instructions, and AFAIK no compiler can generate this code automatically; you use specific functions/macros to read access flash:
https://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.htmlConcepts like this just don't exist on ARM. Complex things are of course difficult, but simple things tend to be simple, which isn't always the case on the 8-bit world!