NXP i.MX · Rockchip RK3588 · Qualcomm QCS6490

ARM Mini-ITX Platforms for Embedded Control, Vision and Edge AI

Compare ARM platforms by real-time control, BSP maturity, camera pipeline, industrial I/O, NPU capability, and production software support.

  • i.MX 93 · 0.5 TOPSLinux + Cortex-M33
  • i.MX 8M Plus · 2.3 TOPSDual ISP + Cortex-M7
  • RK3588 / QCS64906 TOPS / up to 12 TOPS
Compare ARM SoCs Review My ARM Requirements
ARM Mini-ITX platform for embedded control machine vision and edge AI

ARM SoC Comparison

Choose the SoC by System Role, Not TOPS Alone

ARM platforms differ in real-time cores, image processing, industrial interfaces, vendor software, and accelerator toolchains. The best choice is the SoC whose native resources reduce board complexity and software risk.

Platform Key Resources Best Fit Choose Another Platform When
NXP i.MX 93 2× Cortex-A55 @ 1.7 GHz · Cortex-M33 @ 250 MHz · 0.5 TOPS Control-first gateways, HMI, metering, remote I/O, light ML You need stronger vision acceleration or heavier multimedia
NXP i.MX 8M Plus 4× Cortex-A53 @ 1.8 GHz · Cortex-M7 @ 800 MHz · 2.3 TOPS Industrial vision plus deterministic control, CAN FD, TSN and dual-camera work You need substantially more CPU/GPU/NPU performance
Rockchip RK3588 4× Cortex-A76 + 4× Cortex-A55 · 6 TOPS Multi-display, 8K-class media, camera processing and local AI Industrial real-time co-processing or vendor lifecycle policy is the primary constraint
Qualcomm QCS6490 8-core CPU up to 2.7 GHz · up to 12 TOPS · up to 16 GB LPDDR5 Connected multi-camera AI, robotics and high-integration edge systems You need a simpler control-oriented BSP or native CAN/TSN ownership

Linux · RTOS · BSP

On ARM, the Software Stack Is Part of the Hardware Decision

Bootloader, kernel, device tree, GPU/NPU firmware, camera drivers and RTOS code determine whether an ARM board’s interfaces work reliably in production.

Area What to Freeze Why It Matters
Linux / Android Kernel/BSP branch, patches, drivers, device tree, modules An upgrade can change PCIe, USB, MIPI, Ethernet, suspend/resume or boot behavior
Real-Time Domain Peripheral ownership, RTOS image, watchdog, IPC method i.MX 93 can pair Linux on A55 with M33 control; i.MX 8M Plus can pair Linux with an 800 MHz M7
AI / Camera Runtime NPU compiler/runtime, ISP stack, sensor drivers, model conversion path TOPS has little value if the required operators, sensor or camera pipeline is unsupported
Production Image Bootloader, filesystem, configuration, recovery image, update package Hardware revisions must remain compatible with the released software baseline

Camera · ISP · CAN · TSN

Use Native ARM Interfaces Where They Remove Extra Controllers

ARM SoCs are strongest when their native camera, real-time and industrial interfaces match the product. This can reduce bridge devices, PCIe consumption, board area and driver complexity.

Resource Numeric / Standard Reference Selection Value
i.MX 8M Plus Camera 2× MIPI CSI · dual ISP · up to 12 MP · up to 375 MPixels/s Useful when two camera paths and local image processing must coexist with real-time control
QCS6490 Camera Multi-camera platform direction · up to 4 MIPI CSI on current implementations Useful for connected vision systems where camera, AI and wireless integration dominate
CAN FD Up to 64-byte payload vs 8 bytes for Classical CAN Reduces protocol overhead when larger industrial or vehicle messages are required
ISO 11898-1:2024 CAN data-link and physical-coding reference Use as a protocol reference; transceiver, isolation, termination and EMC remain board-level decisions
TSN / IEEE 1588 Hardware-assisted time synchronization where supported Verify MAC/PHY, driver, PTP stack, switch topology and measured timing accuracy

RS-232 / RS-422 / RS-485 Physical-Layer Selection → AI-Ready Platform Selection After the Camera Path Is Defined →

Secure Boot · OTA · Lifecycle

Freeze the ARM Software-Hardware Contract Before Production

Secure Boot Chain

Define which keys sign the bootloader, kernel, device tree, firmware and update package. Platform security features only help when the complete chain is implemented and maintained.

Update and Recovery

Use a defined rollback or recovery path so a failed OTA update or power interruption does not leave an unattended unit unbootable.

BSP Maintenance

Assign ownership for kernel CVEs, bootloader patches, GPU/NPU firmware, wireless firmware and vendor BSP updates throughout the support period.

Board Revision Control

Memory, storage, PMIC, PHY, wireless module and camera substitutions must remain compatible with the released BSP and recovery image.

Validate Boot, Recovery and Production Software Together →

Platform Selection

Move to Another ARM SoC Only When a Measurable Constraint Appears

Primary Requirement Start Here Move When
Linux + deterministic control, CAN/TSN, light ML i.MX 93 You need stronger camera/ISP or AI performance
Dual-camera vision + M7 real-time control i.MX 8M Plus 2.3 TOPS or A53 performance becomes the bottleneck
8K-class media, multi-display, 6 TOPS local AI RK3588 Security, lifecycle or enterprise multi-camera integration becomes more important
Connected multi-camera AI, up to 12 TOPS QCS6490 CUDA / TensorRT / JetPack becomes mandatory
CUDA ecosystem is non-negotiable NVIDIA Platform Do not choose another ARM SoC only because it uses the same CPU instruction-set family

ARM Platform Review

Send the Software and I/O Constraints First

Provide SoC preference, Linux/Android/RTOS, camera sensors, CAN/serial, Ethernet, AI runtime, memory/storage, power, enclosure, quantity and lifecycle target.

Submit ARM Platform Requirements

Starting Platforms

Start from the Ecosystem Closest to the Production Software Stack

Direction Best Reason to Start Here Freeze Before Prototype
i.MX 93 Control-first Linux + M33 architecture SoC variant, memory, storage, CAN/TSN ownership, BSP, M33 firmware
i.MX 8M Plus Vision + real-time control in one SoC Camera sensors, MIPI lanes, NPU runtime, Linux branch, M7 partition
RK3588 High multimedia density and 6 TOPS edge AI Vendor BSP, ISP/sensor support, NPU runtime, storage and thermal design
QCS6490 Connected multi-camera AI and strong integrated acceleration Camera set, BSP/OS, wireless, AI runtime, secure boot and lifecycle
Custom ARM Reference Platform No standard board exposes the required SoC resource map Schematic allocation, device tree, BSP, BOM, validation scope and update ownership

FAQ

ARM Mini-ITX Platform FAQ

Why is ARM motherboard selection more software-dependent than x86?

ARM boards are usually tied more closely to the vendor BSP, device tree, camera and NPU drivers, PMIC, bootloader and board-specific I/O. Hardware and software should be qualified together.

When is i.MX 8M Plus more useful than a higher-TOPS SoC?

Choose it when 2.3 TOPS is enough and the project benefits from dual ISP, two MIPI CSI paths, an 800 MHz Cortex-M7, CAN FD and TSN-capable Ethernet in one industrial architecture.

Does a higher NPU TOPS number guarantee faster inference?

No. Model operators, precision, runtime, memory transfers, preprocessing, camera pipeline, power mode and sustained temperature determine real latency and throughput.

What should be frozen before ARM production?

Freeze the SoC, memory, storage, PMIC, I/O map, camera sensors, bootloader, kernel/BSP branch, device tree, RTOS firmware, AI runtime, security keys, recovery method and approved substitutions.

Actionable Insights for ARM-Based Embedded Systems

Stay current with the latest in ARM SoC integration, board-level design tips, and real-world deployment strategies—from low-power edge AI to rugged industrial controls.