7
\$\begingroup\$

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?

\$\endgroup\$
10
\$\begingroup\$

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ I appreciate that you mentioned HAL. How about HALs that vendors provide? Do they obey some kind of standard across processors? \$\endgroup\$ – ozgur Aug 20 '15 at 10:22
  • 4
    \$\begingroup\$ @ozgur To put it mildly is "no". Vendor specific HALs are just there to allow you to work with all of their chips with the same commands. Such as Atmel Software Framework, which is a very nice quick-proto toolset, has some functions the same as other vendor HALs, but nothing is guaranteed and indeed I have not been able to do without my own HAL or HALAL (<- LOL!) to abstract their abstraction. \$\endgroup\$ – Asmyldof Aug 20 '15 at 10:30
  • \$\begingroup\$ @ozgur I have updated my post and expanded it on vendor HALs, I agree with Asmyldof, there is no standard. \$\endgroup\$ – Arsenal Aug 20 '15 at 11:53
  • \$\begingroup\$ @Arsenal Helpful a lot. Thank you very much, really. \$\endgroup\$ – ozgur Aug 20 '15 at 12:02
  • \$\begingroup\$ @Asmyldof now your comment's message is clear. a lack of standard is a shame, though. \$\endgroup\$ – ozgur Aug 20 '15 at 12:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.