Are the common ARM peripherals standardized and code compatible?

[RoGeorge]

Is it expected for common peripherals, like an I2C or a timer, to be the same between different manufacturers, just like the ARM core remains the same between manufacturers?

I mean, the instruction set remains the same and compatible along a given ARM core, but is this compatibility similar between the same type of peripherals, do the peripherals share the same code/libraries?

[Sal Ammoniac]

Usually it's just the ARM core that is common among MCU makers. The peripherals are generally different.

Sometimes different manufacturers buy IP for peripherals from the same source, in which case the peripheral will be the same across different manufacturers, but that's fairly rare.

[coppice]

Don't expect commonality of peripherals between devices. You may find some peripherals common between devices, because the developers of both devices licenced the peripheral designs from the same third party. Most vendors aren't even very consistent about using the same peripheral design across all the devices in their range.

[westfw]

Is it expected for common peripherals, like an I2C or a timer, to be the same between different manufacturers

No.  other than the "peripherals" that are considered part of the ARM core (NVIC, Systick, a few others), they vary quite wildly (even between different "families" from the same vendor.)

[ataradov]

If peripherals are standardized, then there would be no differentiation between the devices. No vendor will ever go for that. This is part of the reason why software side of the CMSIS failed.

[rsjsouza]

Is it expected for common peripherals, like an I2C or a timer, to be the same between different manufacturers

No.  other than the "peripherals" that are considered part of the ARM core (NVIC, Systick, a few others), they vary quite wildly (even between different "families" from the same vendor.)

Indeed. And even some of these (such as Systick, ITM, etc.) may even be optional or proprietary depending on the vendor. Arm gives a lot of options on their IP.

[langwadt]

Is it expected for common peripherals, like an I2C or a timer, to be the same between different manufacturers

No.  other than the "peripherals" that are considered part of the ARM core (NVIC, Systick, a few others), they vary quite wildly (even between different "families" from the same vendor.)

Indeed. And even some of these (such as Systick, ITM, etc.) may even be optional or proprietary depending on the vendor. Arm gives a lot of options on their IP.

sure, but I'd think most include the basics, like NVIC, Systick because that's what is needed for an OS and probably why they are in the core and not peripherals as such

[coppice]

If peripherals are standardized, then there would be no differentiation between the devices. No vendor will ever go for that. This is part of the reason why software side of the CMSIS failed.

People select one MCU over another for the clever peripherals, but not the very basic ones. There are a number of simple peripherals which could have been standardised with no effect on the competitive environment. Its certainly poor practice when you can't even move code from one MCU to another in the same vendor's product range, and expect basic peripheral code to function the same.

[coppice]

Is it expected for common peripherals, like an I2C or a timer, to be the same between different manufacturers

No.  other than the "peripherals" that are considered part of the ARM core (NVIC, Systick, a few others), they vary quite wildly (even between different "families" from the same vendor.)

Indeed. And even some of these (such as Systick, ITM, etc.) may even be optional or proprietary depending on the vendor. Arm gives a lot of options on their IP.

sure, but I'd think most include the basics, like NVIC, Systick because that's what is needed for an OS and probably why they are in the core and not peripherals as such

Before the M series cores we had the ARM7 in MCUs, and even the interrupt controller was not a standard part of that. ARM like to keep things very lean.

[ataradov]

People select one MCU over another for the clever peripherals, but not the very basic ones. There are a number of simple peripherals which could have been standardised with no effect on the competitive environment. Its certainly poor practice when you can't even move code from one MCU to another in the same vendor's product range, and expect basic peripheral code to function the same.

Sure, but standardizing and sticking to the same peripherals ensures no forward progress. You have to break compatibility sometimes to make improvements.

Now, if there was some perfect peripheral that is done and does not need improvement, then we can talk about fixing it. But I personally have not seen anything close to that.

[SiliconWizard]

If you want common peripherals to all look "the same" programming-wise... use the Arduino framework.

[westfw]

There are a number of simple peripherals which could have been standardised

The industry says "nope."  Not even gpio.  (not that GPIO turns out to be "simple", once you consider common features like pin-change interrupts, pull options, drive options, alternate pin functions, etc)

the Arduino framework.

It is really sad that the "Arduino Framework" is pretty much as close as you can get to a multi-vendor abstraction of common peripherals...
You can look at what ARM tried to do for CMSIS-Driver, but ... it's pretty awful.  (Doesn't include GPIO or I2C, either.)
None of the "vendor libraries" have any commonality with each other, either.  (And of course, they tend to want to support every possible feature of the hardware.)

[coppice]

People select one MCU over another for the clever peripherals, but not the very basic ones. There are a number of simple peripherals which could have been standardised with no effect on the competitive environment. Its certainly poor practice when you can't even move code from one MCU to another in the same vendor's product range, and expect basic peripheral code to function the same.

Sure, but standardizing and sticking to the same peripherals ensures no forward progress. You have to break compatibility sometimes to make improvements.

Now, if there was some perfect peripheral that is done and does not need improvement, then we can talk about fixing it. But I personally have not seen anything close to that.

If you want a basic low performance I2C interface, all you want is a basic low performance I2C interface. Now, if you want something fancy, buffered, tricky, low overhead and high throughput there's a reason to make a fancy peripheral. However, in most cases you could make the fancy one support a basic mode that is software compatible with the basic fully standard variant of the peripheral.

[westfw]

in most cases you could make the fancy one support a basic mode that is software compatible with the basic fully standard variant of the peripheral.

Can you?   I mean, that's easy when you're writing a software library, but I'm not sure that it remains easy when you're talking about hardware.  For example, how do you handle bitrate choice (normally done by writing a divisor from some clock signal) in the face of differing system clock rates (and differing clock systems)?   Insist that all peripherals be driven by some fixed-rate clock by default?

And what do you do on something like a SAMD, where all of your serial protocols (USART, SPI, TWI) are handled by one reconfigurable set of "sercom" hardware?

[SiliconWizard]

the Arduino framework.

It is really sad that the "Arduino Framework" is pretty much as close as you can get to a multi-vendor abstraction of common peripherals...
You can look at what ARM tried to do for CMSIS-Driver, but ... it's pretty awful.  (Doesn't include GPIO or I2C, either.)
None of the "vendor libraries" have any commonality with each other, either.  (And of course, they tend to want to support every possible feature of the hardware.)

I don't know if it's "sad". That's actually a matter related to all "cross-platform" solutions. They inevitably hinder performance, innovation and must cater for the lowest common denominator. This is not a truly viable approach for microcontrollers. I for one certainly would not want that if that meant (which would be sort of inevitable) less variety among vendors and lower performance in the end.

[coppice]

in most cases you could make the fancy one support a basic mode that is software compatible with the basic fully standard variant of the peripheral.

Can you?   I mean, that's easy when you're writing a software library, but I'm not sure that it remains easy when you're talking about hardware.  For example, how do you handle bitrate choice (normally done by writing a divisor from some clock signal) in the face of differing system clock rates (and differing clock systems)?   Insist that all peripherals be driven by some fixed-rate clock by default?

And what do you do on something like a SAMD, where all of your serial protocols (USART, SPI, TWI) are handled by one reconfigurable set of "sercom" hardware?

In most cases you can. I've been through this a number of times. If you can't maintain emulation of a simpler peripheral without compromising the design (either performance or size) of a more feature rich peripheral you probably aren't really committed to the idea. If you have a simple USART module, and a simple SPI module, and a simple I2C module and you want to make an all encompassing module, a module with three sets of registers that emulate the three simple modules isn't going to be a big deal. You just need to take care about clash issues.

[ataradov]

You can of course design some common standard for a minimal peripheral. But nobody would go it, since it just introduces another thing vendors need to maintain and verify.

And then, who defines that register set? You would need to get all the major device manufacturers into the same room to discuss this and come up with the standard. This takes away engineering time for no additional profit (actually potential loss of profit due to migration to competitors).

A good example of a cross-vendor collaboration is EEMBC, and it is not going too well. And they are not even defining anything silicon-related.

[westfw]

It's amusing to look at the CMSIS-driver implementaion for USART, which includes a "get capabilities" function that reports what I guess ARM considers to be "common" properties of a USART:

https://www.keil.com/pack/doc/CMSIS/Driver/html/group__usart__interface__gr.html#structARM__USART__CAPABILITIES

(now contemplate either the "simple" UART that supports all of those, or the application code that "should" confirm that the driver supports the features that it wants to use.)

[coppice]

It's amusing to look at the CMSIS-driver implementaion for USART, which includes a "get capabilities" function that reports what I guess ARM considers to be "common" properties of a USART:

https://www.keil.com/pack/doc/CMSIS/Driver/html/group__usart__interface__gr.html#structARM__USART__CAPABILITIES

(now contemplate either the "simple" UART that supports all of those, or the application code that "should" confirm that the driver supports the features that it wants to use.)

Well, a real application is only going to call a few of those things, but they really make no sense. These are embedded systems. If you test for a feature at run time, and find its not there, WTF is the software supposed to do next. Too many of these embedded support systems are put together by people who have only ever developed for big machines.

[SiliconWizard]

CMSIS for peripherals is a good illustration of something that will never be relevant.

[cgroen]

CMSIS for peripherals is a good illustration of something that will never be relevant.

I was going to write the same, just with some much more harsh words....

[Siwastaja]

The only way to pull this of is, ARM the company has to design
* Easy to use
* Simple
* Well performing
* Feature-rich,

in other words, very good peripherals, and then license them to manufacturers such as ST at affordable enough price. Only this will make it happen.

The same is true for the cores itself. It's not that ST or NXP etc. actually want you to easily port between different manufacturers. No, the only reason they use ARM ecosystem is that it's good. Own proprietary solutions would take more time-to-market and still likely perform worse. Writing compilers especially is a lot of work!

The compatibility thing is just a side effect. Possibly even unwanted one to some of the managers at these companies!

Any peripheral compatibility attempt which looks like it's made by a committee for compatibility reasons, is doomed to fail. The only thing that matters is good set of good peripherals, and manufacturers know that.