All microcontrollers can be programmed in a C-like language, all of them have the same basic peripheral types and comparable cores as far as features go. When you stay within the realm of real-time MCUs, they are pretty easy to jump between.
Probably the biggest differences are simply in the idiosyncracies of the tools. If you are accustomed to the ease of having preprogrammed bootloaders in your AVRs (down to pre-programmed USB bootloaders in the -U parts), you may have some trouble with having to buy a compatible JTAG programmer for certain ARM chips. If you're accustomed to the rich debugging features of JTAG-enabled chips, it may be a bit of a culture shock to go back to in-bound debugging in low-end PICs and AVRs. But that's something you get used to after using a toolchain for a while. Also, with some chips there is quite a significant cost associated with using their tools, e.g. Freescale and Renesas.
Don't be afraid to choose a different chip once in a while and learn to work with it. It will broaden your view and enable you to use more optimal MCUs in the future
Addendum: this doesn't really apply when you go to non-realtime processors like the ARM A-series, x86 and Cell. These are very difficult to program for on a low level, tools are expensive and the chips are hard to get and implement.
The free GCC toolchain supports ARM/Cortex just fine. Pre-compiled versions can be found all over the web, or you can build your own. You could do assembler if you want, but I would suggest at least C, personally I like C++ even better because it allows very efficient libraries.
The things that 'hang around' the compiler can be a bit trickier. I wrote my own make scripts, linker scripts, startup code, and some support libraries. That requires some in-depth knowledge, but it is not that much work (at least for the first few chips). I mainly use the LPC DIP chips, LPC1114FN28 and LPC810M021FN8.
I am not a fan of the 'heavy' IDEs. I use mostly PSPpad, but the make-script can be used with any editor that can call a shell script, catch the output, and parse a (GCC) error message.
I am not a fan of debuggers, I prefer to insert print statements. I use lpc21isp for hands-off serial downloading + terminal emulation. Works OK, except that I had to patch lpc21isp it to reset the chip after downloading (instead of using the ISP GO command, which is broken on Cortex. Blame on you NXP for not fixing this!).
An article about how I use C++ can be found here.
In about two weeks I'll have my environment up-to-date for my C-on-LPC1114 course. The last-year version can be found here.
Best Answer
The Preemption Priority allows an ISR to be preempted (interrupted) by another interrupt of higher priority. When the higher-priority interrupt is completed, the lower-priority interrupt continues from where it left off.
Subpriority, on the other hand, has nothing to do with preemption. Say that you have two interrupts of the same priority which are both pending. The interrupt handler will choose which one to service first, based on their subpriority. Once the first one is completed, the second one will begin.
It may seem unlikely that two interrupts can happen at the same time. One common situation where this could happen is if you have an interrupt service routine that takes a long time. During this routine, multiple other interrupt triggers may have taken place. If so, the subpriority will determine which one is handled next.
Finally, keep in mind that as the actual priority increases, the priority value decreases. That is,
Priority=1will be serviced beforePriority=2.