How to Transition from "Basic" Microcontrollers to ARM Cortex?

I've worked on AVRs as well as ARM Cortex-M3/M4/R4-based MCUs. I think I can offer some general advice. This will assume you're programming in C, not assembly.

The CPU is actually the easy part. The basic C data types will be different sizes, but you're using uint8/16/32_t anyway, right? :-) And now all integer types should be reasonably fast, with 32-bit (int) being the fastest. You probably don't have an FPU, so continue to avoid floats and doubles.

First, work on your understanding of the system-level architecture. This means IOs, clocking, memory, resets, and interrupts. Also, you need to get used to the idea of memory-mapped peripherals. On AVR you can avoid thinking about that because the registers have unique names with unique global variables defined for them. On more complex systems, it's common to refer to registers by a base address and an offset. It all boils down to pointer arithmetic. If you're not comfortable with pointers, start learning now.

For IOs, figure out how the peripheral muxing is handled. Is there a central mux control to select which pins are peripheral signals and which are GPIOs? Or do you set pins to peripheral mode using the peripheral registers? And of course you'll need to know how to configure GPIOs as inputs and outputs, and enable open-drain mode and pull-ups/downs. External interrupts usually fall into this category as well. GPIOs are pretty generic, so your experience should serve you well here.

Clocking boils down to a few things. You start with a clock source, typically a crystal or internal RC oscillator. This is used to create one or more system-level clock domains. Higher-speed chips will use a PLL, which you can think of as a frequency multiplier. There will be also clock dividers at various points. They key things to consider are what your CPU clock frequency should be and what bit rates you need for your communication peripherals. Usually this is pretty flexible. When you get more advanced, you can learn about things like low-power modes, which are usually based on clock gating.

Memory means flash and RAM. If you have enough RAM, it's often faster to keep your program there during early development so you don't have to program the flash over and over. The big issue here is memory management. Your vendor should provide sample linker scripts, but you might need to allocate more memory to code, constants, global variables, or the stack depending on the nature of your program. More advanced topics include code security and run-time flash programming.

Resets are pretty straightforward. Usually you only have to look out for the watchdog timer, which may be enabled by default. Resets are more important during debugging when you run the same code over and over. It's easy to miss a bug due to sequencing issues that way.

There are two things you need to know about interrupts -- how you enable and disable them, and how you configure the interrupt vectors. AVR-GCC does the latter for you with the ISR() macros, but on other architectures you might have to write a function address to a register manually.

Microcontroller peripherals are usually independent of each other, so you can learn them one at a time. It might help to pick one peripheral and use it to learn part of the system-level stuff. Comm peripherals and PWMs are good for clocking and IOs, and timers are good for interrupts.

Don't be intimidated by the level of complexity. Those "basic" microcontrollers have already taught you much of what you need to know. Please let me know if you need me to clarify anything.

It's useful to remember that ARM owns the intellectual property for the microprocessor, but doesn't actually make parts. Instead, manufacturers license the various ARM processor versions and produce their own unique parts with individual mixes of features and peripherals.

With that said, if you're new to the architecture, it would probably make sense to start with ARM's documentation which is, essentially, the baseline documentation for all such microprocessors.

For example, the Cortex-M0 is described on ARM's website.

There is also a list of ARM-related books which caters to a wide variety of needs and interests.

Finally, there are the specific manufacturer's datasheets. For the M0, Cypress, NXP and STMicroelectronics are just three of the many manufacturers of real parts based on the Cortex-M0.

(And no, I don't work for ARM and never have.)

One big difference is the use of vendor-supplied libraries. For the PICs, Atmels, etc, the basic libraries (for gpio, timers, adc, etc) weren't used much by most developers. In my experience, people would (at most) use them as guides when writing their own code.

However, with ARM, the libraries are almost always used. There is a standard, "CMSIS", that manufacturers are recommended to follow. Most do. It aids in code portability (between different ARMs and between manufacturers), and gives a "standardized" method for structuring your code. People get used to seeing and understanding the library functions.

Sure there are some developers that access the registers directly, but they're the outliers :)

To answer your question, I found it very helpful to read through the Library documentation. ST has well-developed code, with a large Doxygen-created help file. You can see what all the options are for each hardware module.

To use GPIO as an example, the initialization function handles:

• Direction (In or Out)
• pullups/pulldowns
• open-collector/push-pull
• slew rate
• etc.

By looking at the options, you can see what is possible. And, of course, you'll learn how to pass these options into the Init function!

OK, now that I've said that, I see that your specific ARM doesn't have CMSIS-compliant libraries. Instead, they have their proprietary SDK available for download. I would start looking though their SDK docs.

If you're not married to this specific product, I might recommend that you find a different vendor with more compliant libraries. You're going to climb a learning curve anyway, so you might as well make your investment more portable...

ARMs are fun! I haven't looked back.