What Is Arm Architecture? Arm Processors in Embedded and Industrial Systems

Arm architecture is a family of RISC (reduced instruction set computer) instruction set architectures, designed by Arm Holdings and licensed to chip makers, that defines the instructions a processor understands and how software talks to it. Arm does not make chips itself: companies such as NXP, Qualcomm, Rockchip, Texas Instruments and NVIDIA build systems on chip from Arm’s processor cores, or design their own cores under an architecture licence.

That model is why Arm is everywhere. It runs almost every phone, most low-power embedded devices, a growing share of edge AI hardware and, through modules such as NVIDIA Jetson, many robots and vision systems. It is also why two Arm processors can differ enormously in graphics, AI, memory and I/O even though both are Arm.

This guide explains how the licensing works, why Arm counts as RISC, the architecture versions from Armv7 to Armv9, the Cortex-A, Cortex-R and Cortex-M profiles, the Arm chips found in industrial boards, and what to check before you design one in.

Arm makes its money from licences and royalties rather than from selling chips. A chip maker can license a finished core design, such as a Cortex-A55, and place it in its own system on chip next to its own graphics, AI engine, memory controller and I/O. Or it can take an architecture licence and design its own cores that run the Arm instruction set. Either way, software built for the Arm architecture runs on the result.

In industrial computing almost every Arm processor uses licensed Cortex or Neoverse cores, so the difference between two boards lies in the rest of the SoC and in the vendor’s software and longevity; our guide to CPU generations and embedded processors shows how Arm parts are named alongside Intel and AMD. Our guide to the system on chip explains what sits around the cores.

Yes. Arm began as the Acorn RISC Machine in the 1980s, and its instruction set follows RISC principles: simple instructions that mostly complete in one cycle, a load and store model in which only dedicated instructions touch memory, and a large set of registers. x86, by contrast, is a CISC design with variable-length instructions that can operate on memory directly, though modern x86 processors break those instructions into simpler operations internally.

The practical difference today is less about RISC and CISC than about how the chips are built and what software runs on them. Our comparison of x86 and Arm covers that in depth, so this guide stays on the Arm side.

The architecture version defines the instruction set a core implements, and each version added capabilities that still shape which boards suit which jobs. Many long-life industrial boards still run Armv7 parts, while new designs are almost all Armv8-A or Armv9-A.

So is Arm 64-bit? Every Armv8-A and Armv9-A application core can run 64-bit code, and most Linux distributions for industrial Arm boards are now 64-bit. Some newer cores drop 32-bit application support altogether, which matters if a project carries old 32-bit binaries. Jetson Thor’s Neoverse V3AE cores, for example, are an Armv9 server-class design adapted for automotive and industrial safety.

Arm started at Acorn Computers in Cambridge, where a small team designed the Acorn RISC Machine in the mid-1980s for the company’s own computers. In 1990 Acorn, Apple and VLSI Technology spun the design team out as Advanced RISC Machines, and the new company chose to license its designs rather than build chips. That decision shaped everything after it.

Low power made Arm the default in mobile phones through the 1990s and 2000s, with cores such as the ARM7TDMI and ARM9. The Cortex brand arrived with Armv7 in the mid-2000s and split the line into the A, R and M profiles, and Armv8-A brought 64-bit computing in 2011. Arm was bought by SoftBank in 2016 and returned to the stock market in 2023. Along the way the same efficiency that suited phones carried Arm into embedded boards, cars, servers and edge AI modules.

Most new Arm SoCs for industrial use carry an AI engine beside the CPU cores, because running a neural network on the cores alone is slow and power-hungry. The engine takes one of three forms, and the form decides how large a model the chip can run and which tools a team uses to deploy it.

TOPS figures are a rough guide, because precision, sparsity and the toolchain all change what a chip delivers on a real model; our explainer on what TOPS means covers the caveats, and our guide to what an NPU is explains the hardware. Each vendor has its own toolchain for converting and quantising models, so check that it supports your framework before choosing the chip.

Arm divides its cores into profiles for different jobs. The profile, more than the version, tells you what software a core can run and what it is for.

Many industrial SoCs combine profiles on one chip. The NXP i.MX 8M Mini pairs four Cortex-A53 cores with a Cortex-M4, and the i.MX 8M Plus adds a Cortex-M7, so Linux runs on the A cores while the M core handles a time-critical control loop or sampling task on its own. That split gives real-time behaviour without a separate microcontroller, and it is a common reason to choose Arm for control equipment.

Arm introduced big.LITTLE so that a chip could carry fast, power-hungry cores and small, efficient cores together, moving work between them as load changes. DynamIQ, from 2017, lets both kinds sit in one cluster with shared cache. Most current industrial Arm SoCs use it: the Rockchip RK3588 combines four Cortex-A76 with four Cortex-A55 cores, and the RK3576 four Cortex-A72 with four Cortex-A53.

The idea is the same one Intel adopted with performance and efficient cores in Alder Lake, and it raises the same questions for embedded software: which tasks run on which cores, and how real-time threads are pinned so they do not land on a slow core at the wrong moment. Our guide to P-cores and E-cores covers the Intel side.

Partly the instruction set, and mostly the way Arm chips are designed. A simpler decoder needs fewer transistors, the cores are tuned for performance per watt rather than peak speed, and the SoC integrates the GPU, NPU, video engine and I/O so that data does not cross the board between chips. Clock and power gating switch off parts of the chip that are idle, and big.LITTLE moves light work onto small cores.

In an industrial product, that efficiency turns into a smaller heatsink, a sealed fanless enclosure, a longer battery life or a computer that runs from PoE. Many Arm boards in our range draw a few watts, against 6 to 15 W for a low-power x86 board, which is often the deciding factor in a sealed or battery-powered device.

These are the Arm SoC families most often found in industrial boards and computers. Each vendor runs its own longevity programme and software support, which matter as much as the cores.

Our hubs for NXP, Qualcomm and Rockchip list every board and computer by processor, and our explainer on the Qualcomm Hexagon NPU covers the AI engine in Qualcomm’s parts. For the AI side of Jetson, see what NVIDIA Jetson is.

An x86 board boots a standard operating system from UEFI firmware, much like a PC. An Arm board usually depends on a board support package from its maker: the boot loader, typically U-Boot, a kernel with the board’s drivers and a device tree that describes the hardware. Application teams build on it, either as a ready Linux image or as layers for the Yocto Project, so the quality of the BSP and the maker’s update policy decide how easily the product can be patched later.

Can Arm run Windows? Yes, on Qualcomm processors that Microsoft supports, and Windows on Arm can run many x86 applications through emulation, though more slowly than native code and not for drivers. For most industrial Arm boards Linux is the practical choice, and our introduction to embedded Linux explains the common approaches.

Arm builds hardware isolation into the architecture. TrustZone splits a processor into a normal world, where Linux and the application run, and a secure world that holds keys, runs trusted services and checks firmware. On Cortex-A parts, a trusted execution environment such as OP-TEE runs in the secure world; Cortex-M parts from Armv8-M onwards have their own TrustZone for microcontrollers.

These features help a product meet standards such as IEC 62443, but only if the BSP enables them and the image is built to use them. Our IEC 62443-4-2 hardware security checklist sets out what to ask a supplier.

Arm is the natural choice when power, size and integration lead the specification and the software can be built for Linux or Android. x86 remains simpler when the application already runs on Windows or depends on PC drivers. The table is a quick guide; the x86 and Arm comparison mentioned earlier goes further.

Arm boards rarely replace an x86 industrial PC one for one. They tend to appear where the device is small, sealed, battery or PoE powered, or built in large numbers at a tight cost, and where the software is written for Linux or Android from the start.

Our industrial IoT gateways and digital signage players include Arm models alongside x86 ones, so the choice can follow the software rather than the catalogue.

These boards and systems cover the main Arm families. We configure the boot loader and image, install the operating system and application, and test each one before it ships.