I have started developing applications on XMC 2 go evaluation board. I, more or less, got the idea. But what if I try to go for, lets say, STM32?
For XMC1100 setting pin 00 as output is
PORT1->IOCR0 &= ~PORT0_IOCR0_PC0_Msk;
PORT0->IOCR0 |= 0x0 << PORT0_IOCR0_PC0_Pos;
But I don't think stm32 has a IOCR register. So, should an engineer learn all these different register names?
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.
