The reality in microcontrollers is that code space is at a premium. Being able to reduce the size of the instructions reduces the size of code and enables packing more code into the same flash. The Thumb instruction set enables the programmer to get a lot more out of the ARM, but it has its caveats and so must be used carefully. This is because there are tradeoffs to having fewer bits and so the instruction capability is reduced. Still, a good compiler can help you utilize this feature.
Thumb2 tried to improve upon this and bridge the gap between the limits of instructions in Thumb and the ones for the 32-bit instructions.
Yes it does. While all Cortex M controllers will share the same core, and some of the core peripherals, all other peripherals are vendor specific.
Even using CMSIS won't help you much in that scenario as it will only cover things provided by ARM, which is the core and the core peripherals (NVIC, Systick...)
So in the end if you switch from one vendor to another, you will have to read the data sheet, the reference (or user) manual and figure out how stuff works. You don't necessarily have to learn every register names as vendors now provide peripheral libraries which put an abstract layer on top of the hardware.
But it's not hard or challenging, it's what you gotta do - I'd say it's even one of the more fun parts figuring out how those peripherals work.
And after you realized this, you might want to write a Hardware Abstraction Layer to prevent your firmware being completely unusable for another controller. If you have a stable HAL, you can at least get the device drivers and application layers over to your next controller and only have to implement the HAL again.
Even though the vendors offer peripheral libraries, which function as a HAL, there is no standard across vendors. So at the lowest level you will have to adapt your software, which is why I said, that you yourself might want to write a HAL (in which you can use the HAL of the vendor).
If you want to implement a stable HAL, your features will most likely be limited to the very basic functionality of the common peripherals, so every controller can be abstracted. Typically you will loose some more advanced features of the peripherals, because they are not available everywhere (say a baudrate detection mechanism or automatic dead time between PWM channels). That will be the price to pay. If we need those mechanisms for our application, we write a specialized hardware driver for that purpose, so the rest can still work with the common HAL.
Using this approach I ported an application to two other microcontrollers just implementing the HAL, the rest could be compiled without a single change in the software.
Best Answer
I managed to fix my problem by adding the following near the beginning:
I had not started the HSE so most of the configuration was propably just ignored as the core still worked.
As a sidenote also the
HCLK
,PCLK1
andPCLK2
divisions were incorrect (over the frequency limit.) I had not spent so much attention on those as I tried to find out whySYSCLK
was not getting set correctly.