Are the common ARM peripherals standardized and code compatible? - Page 1
Forum section: electronics / general

author: RoGeorge
author_rank: Super Contributor
timestamp: February 18, 2022, 09:51:13 pm
content: 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?

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: February 18, 2022, 10:00:36 pm
content: 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.

author: coppice
author_rank: Super Contributor
timestamp: February 18, 2022, 10:08:18 pm
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: February 18, 2022, 11:41:43 pm
content: QuoteNo. 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.)

author: ataradov
author_rank: Super Contributor
timestamp: February 19, 2022, 01:03:47 am
content: 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.

author: rsjsouza
author_rank: Super Contributor
timestamp: February 19, 2022, 01:40:59 am
content: Quote from: westfw on February 18, 2022, 11:41:43 pmIndeed. 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.

author: langwadt
author_rank: Super Contributor
timestamp: February 19, 2022, 02:01:40 am
content: Quote from: rsjsouza on February 19, 2022, 01:40:59 amsure, 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

author: coppice
author_rank: Super Contributor
timestamp: February 19, 2022, 02:49:08 am
content: Quote from: ataradov on February 19, 2022, 01:03:47 amPeople 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.

author: coppice
author_rank: Super Contributor
timestamp: February 19, 2022, 02:51:04 am
content: Quote from: langwadt on February 19, 2022, 02:01:40 amBefore 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.

author: ataradov
author_rank: Super Contributor
timestamp: February 19, 2022, 03:15:44 am
content: Quote from: coppice on February 19, 2022, 02:49:08 amSure, 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 19, 2022, 03:25:17 am
content: If you want common peripherals to all look "the same" programming-wise... use the Arduino framework.

author: westfw
author_rank: Super Contributor
timestamp: February 19, 2022, 03:37:52 am
content: QuoteThe 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)QuoteIt 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.)

author: coppice
author_rank: Super Contributor
timestamp: February 19, 2022, 03:43:48 am
content: Quote from: ataradov on February 19, 2022, 03:15:44 amIf 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.

author: westfw
author_rank: Super Contributor
timestamp: February 19, 2022, 07:30:17 am
content: QuoteCan 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?

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 19, 2022, 06:06:25 pm
content: Quote from: westfw on February 19, 2022, 03:37:52 amI 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.

author: coppice
author_rank: Super Contributor
timestamp: February 19, 2022, 06:23:33 pm
content: Quote from: westfw on February 19, 2022, 07:30:17 amIn 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.

author: ataradov
author_rank: Super Contributor
timestamp: February 19, 2022, 06:29:57 pm
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: February 20, 2022, 12:24:40 am
content: 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.)

author: coppice
author_rank: Super Contributor
timestamp: February 20, 2022, 01:34:27 am
content: Quote from: westfw on February 20, 2022, 12:24:40 amWell, 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 20, 2022, 03:41:15 am
content: CMSIS for peripherals is a good illustration of something that will never be relevant.

author: cgroen
author_rank: Unknown
timestamp: February 20, 2022, 03:53:31 am
content: Quote from: SiliconWizard on February 20, 2022, 03:41:15 amI was going to write the same, just with some much more harsh words....

author: Siwastaja
author_rank: Super Contributor
timestamp: February 20, 2022, 08:59:39 am
content: 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 goodperipherals, 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'sgood. 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.