Why Mixed RTOS and Linux (AMP) Architectures Break Determinism Under Real Industrial Load
The board came up cleanly. Linux on the Cortex-A cores ran the HMI, the network stack, and the OPC UA server. An RTOS on the Cortex-M side ran a high-rate current loop and a lower-rate position loop. RPMsg carried setpoints and telemetry between them. On the bench, at nominal load, the position loop held its target cycle time with no missed deadlines for hours.
Then the machine went into commissioning. A field-tuning session over the plant Ethernet — nothing exotic, moderate MQTT traffic and a large log dump — coincided with an increase in current-loop worst-case execution time, and every so often the RTOS side saw an RPMsg round trip drift well past its usual figure while the Linux side was serving a diagnostic query. The Linux side reported nothing wrong. The RTOS side reported the missed deadlines as they happened, but by then the servo had already overshot.
The board was fine. Both operating systems were fine. What had never been engineered was the boundary between them — the shared memory subsystem, the interconnect priorities, the reserved-memory placement, the interrupt routing, and the assumption that “separate cores” meant “separate timing domains.” On many SoCs, cores that run different OSes still share the same DRAM controller, the same on-chip interconnect, and often the same DMA engines; the degree to which that coupling shows up depends on the code and data placement and on the platform’s local-memory options (for example, TCM on real-time cores when it is available), not on any category-level rule.
This is the gap that AMP designs consistently walk into. The two operating systems are correct. The IPC library works. The demo behaves. The facility is where the unmodeled contention lives.
- Note: the scenario above is a composite drawn from patterns Promwad and the wider embedded community see repeatedly on heterogeneous industrial SoCs. Specific figures for your target should come from measurements on that silicon under your workload.
- Teams typically assume: if the RTOS core has its own OS, its own cache, and its own IRQs, Linux activity on the other cores cannot degrade real-time behavior.
- In reality: the RTOS and Linux still share resources on the same silicon — the DRAM controller, the interconnect, DMA engines, sometimes cache lines on IPC buffers, and often clock and power trees. How much any single one of those matters is target-specific, but none of them is automatically neutralized by putting the two OSes on different cores.
Quick Overview
Problem: A heterogeneous SoC design that passes RTOS-side timing tests in isolation misses deadlines once Linux runs its real workload — network stack, storage, HMI, diagnostics — on the same silicon.
Common causes: Uncontrolled contention on the shared memory subsystem between Linux and the RTOS core (where the real-time code and data actually sit in shared DRAM rather than in local memory such as TCM), IPC buffers placed without a clear coherency model, peripheral ownership assigned twice, interrupt routing left at defaults, and a Linux side whose worst-case latency has never been characterized on the target — with or without PREEMPT_RT.
Where it appears: Robotics controllers, industrial motion and CNC platforms, machine-vision gateways, motor-drive control units, safety I/O modules migrating from a dual-MCU baseline to a heterogeneous SoC, and industrial HMI where the same box also runs a control loop.
Engineering focus: Memory-bandwidth budgeting, IPC latency validated under production Linux load, peripheral partitioning through the device tree and the SoC firewall, and a Linux-side timing argument built on the target — not inherited from the vendor evaluation kit.
Why a Bench Test Passes and the Machine Does Not
A bench test on a heterogeneous SoC is a controlled environment built to succeed. Linux is idling on the login prompt, or maybe running an ssh session. The RTOS core has the memory controller effectively to itself. The IPC layer transports fewer messages per second than a live control loop generates in a burst. Under those conditions Zephyr, FreeRTOS, or the vendor RTOS on the real-time cores meets its timing exactly as specified.
The production system breaks every one of those conditions at once.
An AMP design partitions execution — separate operating systems on separate cores — but it does not automatically partition the physical resources those cores share. On most industrial SoCs the DRAM controller and the on-chip interconnect are the two shared resources that matter most, along with DMA engines and, in some parts, shared cache. When and how much each of those actually couples the two OSes depends on where the RTOS-side code and its hot data live (shared DRAM, local memory such as TCM, or a mix) and on what the Linux side is doing at any given moment. A demo hides all of it because only one significant consumer is running at a time.
There are four places where a real machine does the pulling apart.
Memory-subsystem contention. If the real-time code and its working set live in shared DRAM, the RTOS core and the Linux side compete for the same LPDDR channel. A Linux process copying a firmware image, a video pipeline pulling frames from the ISP, or a burst of network traffic through the Ethernet DMA can steal bandwidth and add latency to any RTOS-side load or store that reaches DRAM. Whether this dominates the RTOS-side jitter budget is target-specific: on SoCs where the real-time core has its own tightly-coupled memory (TCM on Cortex-M/R, dedicated banks on some architectures) and the hot control code fits there, the effect is much smaller than on a design that keeps everything in shared DRAM. On heterogeneous parts such as i.MX 8M Plus, STM32MP2, TI AM64x, and Zynq UltraScale+ MPSoC, this is one of the coupling points that has to be measured, not assumed away.
IPC path assumptions. RPMsg over VirtIO is not free. Every message crosses at least one shared-memory ring, at least one mailbox or software-generated interrupt, and — depending on whether the shared buffer is treated as cacheable on both sides and how coherency is handled — one or more cache-maintenance operations. RPMsg round-trip time can drift under Linux-side load, and the RTOS side has limited visibility into why; the real causes need to be separated between message processing on the Linux side, IRQ scheduling, shared-memory contention, cache coherency behavior, and queue occupancy, rather than blamed on a single mechanism up front.
Peripheral and clock-tree coupling. “The RTOS owns UART3 and the SPI2 controller” is not a partition until it is enforced. On many industrial SoCs, peripherals share clock domains, power domains, and a security policy enforced by a resource-domain controller or firewall (RDC on i.MX, ETZPC on STM32MP, XMPU/XPPU on Zynq UltraScale+) that has to allow the RTOS core to touch the peripheral without going through Linux. Getting the device tree and the firmware permissions correct is the difference between a partition and a suggestion.
Interrupt routing. Interrupt architecture on a heterogeneous SoC is platform-specific. On the Linux side, Cortex-A cores go through the GIC (ARM Generic Interrupt Controller), and SPI affinity is configurable there. On the real-time side, Cortex-M cores use their own NVIC, Cortex-R cores use the appropriate ARM interrupt controller for that class, and the partitioning of a physical peripheral interrupt between the application-processor domain and the real-time domain is handled by SoC-specific interrupt routing (for example, the interrupt multiplexer / router on i.MX, the ExtInt/IRQ steering on STM32MP2, or the PL/PS partitioning on Zynq UltraScale+). The correct configuration is one careful bring-up decision per platform, not a Linux-side runtime tuning.
How the Layers Interact — and Where the Timing Failure Actually Sits
The most expensive debugging mistake on an AMP system is treating the two operating systems as independent. They are not. A stall in one surfaces as a missed deadline on the other, two subsystems away from the cause.
Walk the real path of one control cycle:
sensor → ADC → MCU/RTOS ISR → control law → RPMsg to Linux (setpoint update, telemetry) → Linux application → OPC UA / HMI / storage → periodic write-back → interconnect arbitration → LPDDR controller → back to the RTOS side
That path crosses two schedulers, one shared memory controller, one interconnect, and typically at least one DMA engine. Now look at where the visible symptom and the real cause separate.
Memory-Subsystem Contention Shows Up as RTOS Jitter
When the real-time code and its working set live in shared DRAM, the RTOS core does not report “Linux is saturating the memory controller.” It reports that an ISR took longer than its usual figure. The audit trail on the RTOS side ends at the load instruction that took longer than it should have; the cause is typically a period where another master — Ethernet DMA, ISP, GPU display path — had traffic in flight at the same instant. The cure is upstream: place hot control code and data in local memory (TCM on Cortex-M/R when available), configure interconnect QoS to favor RTOS traffic, and validate the outcome against production Linux load rather than an idle system.
Uncached vs. Cached IPC Buffers Show Up as “RPMsg Is Slow”
If the RPMsg vrings are placed in non-cacheable memory to avoid coherency headaches, every message pays a full DRAM round-trip on read. If they are placed in cacheable memory without arrangement for coherency between the A-class and the M/R-class core, some messages arrive and some do not, and the ones that do arrive contain stale data intermittently. Both cases look the same at the application layer: “RPMsg is unreliable.” The fix lives in the memory attribute layout, not in the RPMsg library.
A Linux Workload Shows Up as a Missed Control Deadline
This is the signature AMP failure. Linux does something it has always done — a `logrotate`, an OPC UA reconnection, an OTA image download — and the RTOS core misses a deadline that has passed for weeks. The Linux side sees no problem because the Linux side does not have a deadline. The RTOS side had one and cannot say what took the time. Building a worst-case response-time bound that includes cross-domain interference is the analysis that catches this before the machine ships.
Peripheral Contention Shows Up as a Driver Bug
Both sides touch the same I²C bus, the same SPI, or the same GPIO bank — sometimes because the device tree quietly gave the peripheral to Linux while the RTOS firmware also drives it, sometimes because a shared bus was never partitioned in the first place. The symptom is a driver that “sometimes locks up.” The cause is that the two sides are racing on a bus arbiter that has no notion of them being different subsystems.
The reason this class of failure is hard is that no single team owns it. The RTOS firmware engineer, the Linux BSP engineer, and the SoC-integration lead each see a healthy subsystem. The fault lives in the seams, and the seams are what a single-workload bench test skipped.
Four Failure Patterns You Will See in Production
Pattern 1 — The Fast Loop That Passes at Idle and Slips Under Ethernet
A high-rate motor-control loop runs on a Cortex-M or Cortex-R core, with Linux on the application-processor side handling an industrial protocol master or heavy connectivity through a userspace stack. In isolation, current-loop jitter is negligible. As soon as production-rate traffic on the Linux side ramps up, current-loop worst case grows. Candidate causes are DRAM contention when the RTOS-side working set sits in shared memory, DMA activity on the same interconnect, and — on some SoCs — arbitration behavior at the memory controller. Diagnosis proceeds by measurement on the target, not by assumption.
Pattern 2 — RPMsg Latency That Drifts Under Sustained Linux Load
An RPMsg round-trip that measures cleanly at boot degrades over hours of production operation. The RTOS-side timestamps show consistent scheduling. The Linux-side load averages look normal. Candidate causes are several, and telling them apart needs instrumentation: message-processing latency on the Linux side (kernel work queues, thread scheduling), IRQ scheduling of the RPMsg notify path (especially under PREEMPT_RT with the wrong priority map), shared-memory contention with other traffic on the same interconnect, cache coherency work on the shared IPC buffers under the platform’s specific memory attributes, and back-pressure caused by queue occupancy. The correct next step is to instrument each stage separately, not to attribute the drift to a single mechanism up front.
Pattern 3 — “The Peripheral Locks Up After Flashing”
A field firmware update rewrites the Linux rootfs. After reboot, a peripheral the RTOS is supposed to own returns intermittent errors. A common cause is a device-tree overlay change that quietly re-enabled the Linux driver node for that peripheral, so both sides now try to arbitrate the same bus. No error, no dmesg entry — just a race that used to lose one way and now loses the other. The fix is on the ownership side: disable the peripheral in the Linux device tree, enforce the exclusion at the SoC firewall or resource-domain controller, and validate that Linux really cannot reach the peripheral after the update.
Pattern 4 — Works With Stock Linux, Fails With PREEMPT_RT
Counter-intuitive, but it happens. Enabling PREEMPT_RT changes IRQ threading and priority inheritance on the Linux side; if the RPMsg IRQ handler ends up on a threaded IRQ with the wrong RT priority, the wake-up path the RTOS core depends on can add latency it did not have before. PREEMPT_RT is not a checkbox — the priority map has to be engineered for the workload, and on a design where all the hard real-time work is on the RTOS core, stock Linux may be the correct choice.
Where Cross-Domain Engineering Actually Closes the Gap
AMP failures in industrial products are rarely fixed inside either operating system alone. Closing them is a cross-domain engineering task: memory-map layout, interconnect priorities, interrupt routing, and the IPC contract as a design artifact rather than a library choice. These are the domains Promwad covers as an engineering partner — Linux and Android kernel engineering, MCU firmware on RTOS and bare-metal, Zephyr RTOS-based firmware, and SoC / MPSoC integration — together with the industrial-controller, robotics, and machine-vision experience the same team applies at the product level.
A Delta Robot Where the Loop Was Split Across an Application Host and Dedicated Drives
Splitting the Loop Across the Platform
Not every response-time story lives in a post-mortem. Some are visible in the shape of a delivered product. Promwad’s delta robot for high-speed conveyor picking is an example of the architectural principle behind an AMP split: keep each part of the control hierarchy on the compute domain where it belongs.
The delivered platform uses an NVIDIA Jetson Orin Nano running Linux + RTOS as the application controller, coordinating three Infineon XMC4800 servo drives over EtherCAT. The current loop stays on the drive — where its bandwidth is set by the electrical parameters of the motor rather than by any application scheduler — while higher-level trajectory generation runs on the application side. The Jetson Orin Nano’s application processor uses Cortex-A78AE cores, so the split here is between an application-processor host and dedicated servo drives across EtherCAT rather than a single-chip Cortex-A + Cortex-M/R AMP inside one SoC. The general lesson is the same: choose which loop closes where, and let the wire and the scan be terms in that story rather than the story itself.
The same principle recurs in the reusable robotics software platform with EtherCAT, ROS 2 and 5G on Qualcomm RB3 + Hilscher netX 90, where real-time motor-control firmware on the netX 90 handles the deterministic side alongside ROS 2 and 5G on the application processor. That project is a cross-chip split, not a single-SoC AMP either, but it illustrates the same architectural discipline: motion kept inside its own timing domain, the general-purpose OS running alongside rather than over it.
How to Approach a Mixed RTOS + Linux Timing Failure
Step 1: Build the Interference Model Before Trusting the Bench Number
The RTOS-side worst-case execution time measured with Linux idle is a floor, not a ceiling. Rebuild the number with Linux doing what it will do in the field — network traffic at production rates, storage under log rotation, HMI rendering at the target frame rate, and any AI or vision workload the same SoC hosts. The interference is what closes the timing budget, and it will only appear when the memory controller and the interconnect are under realistic pressure.
Step 2: Engineer the IPC Contract, Not Just the IPC Library
RPMsg, or a lighter alternative such as RPMsg-Lite for constrained targets, works. What has to be engineered is the contract underneath: which memory region, cacheable or not, coherency handled by hardware or software, ring size sized for burst behavior, back-pressure semantics on both sides, and a defined action when a ring fills. The library ships with defaults; production needs decisions.
Step 3: Partition the Peripherals in the Device Tree and Enforce It in Firmware
Every peripheral the RTOS owns has to be disabled on the Linux side in the device tree, cross-checked against the SoC firewall or resource domain controller so Linux cannot touch it accidentally, and validated by attempting the access from Linux and confirming it is refused. On SoCs with an M-core or R-core boot-early sequence (i.MX 8M Plus, STM32MP2, Zynq UltraScale+), decide whether the RTOS or Linux configures the shared clock tree — one of them has to, and the wrong choice creates a race at every warm reboot.
Step 4: Configure Interconnect QoS and Interrupt Routing as First-Class Artifacts
On many industrial SoCs, the interconnect (NIC-400, NoC, or the vendor equivalent) exposes QoS knobs that raise the priority of RTOS-relevant transactions to the memory controller. Where they exist, they are boot-time settings that Linux distributions rarely change. Interrupt routing is platform-specific: on the Linux side, SPI affinity in the GIC keeps interrupts off cores you want to protect; the real-time core has its own interrupt controller (NVIC on Cortex-M, the appropriate ARM controller on Cortex-R), and the partitioning of a physical peripheral interrupt between the two domains is handled by SoC-specific interrupt routing — for example, the interrupt multiplexer / router on i.MX, the ExtInt/IRQ steering on STM32MP2, or the PL/PS partitioning on Zynq UltraScale+. Get all three consistent, or you land in a state where the peripheral fires and the wrong core services it.
Step 5: Validate Under Sustained Production Load, Not a Short Run
The drift, the RPMsg latency growth, and the after-flash peripheral race all share a root cause: they were tested at the wrong scale for the wrong duration. Run the full workload — production network traffic, production HMI, the OTA-update path, thermal soak — for hours, and separate the metrics you look at. For hard real-time paths the pass criterion is a defensible worst-case response-time bound: WCET analysis on the target, plus stress on the target that tries to break it, plus a record of any deadline misses. The observed distribution (p99, p99.9, the maximum measured across the run) is a field metric that describes how the system behaves and is useful for spotting drift, but a high percentile is not a proof of a bound — a system that hits its target 99.9% of the time and misses at 0.1% is still missing deadlines, and on a fast loop that adds up quickly. Argue the bound; use the percentile to catch regressions.
If your current acceptance plan does not include a Linux-side stress load co-running with the RTOS-side timing test on the target silicon, that gap is where post-integration surprises originate.
A Robotics Platform Where the Split Was Enforced in Hardware
A Universal Robotics Platform Where Perception and the Industrial Bus Live in Separate Timing Domains
When a robotics program wants to run navigation, vision, and Isaac ROS 2 workloads on a Jetson Orin platform while also carrying deterministic industrial cyclic traffic to the drives, one common design choice is to run the industrial protocol stack on the same host as perception. That choice creates exactly the kind of coupling this article opens with: two workloads with very different timing needs contending for the same host scheduler, the same interconnect, and the same memory bandwidth.
The universal Nvidia robotics platform Promwad delivered solves the split at the hardware boundary instead. A Hilscher netX communication controller runs the industrial protocol stack (EtherCAT, PROFINET, EtherNet/IP) independently of the Jetson host. The two sides exchange process data over PCIe through a defined memory boundary — Dual-Port Memory or DMA — so the industrial stack keeps its own timing while the host runs perception without blocking on the wire. This is a hardware-level partitioning between an application processor and a dedicated communication controller, which is a different mechanism from a single-SoC Cortex-A + Cortex-M/R AMP split, but it addresses the same category of problem: keeping deterministic traffic out of a scheduler that was never designed for it. The related engineering write-up on NVIDIA Jetson industrial Ethernet integration explains why running the industrial stack on the same host as perception is the class of architectural choice this article opens with — and why the fix is a boundary decision, not another optimization pass.
Real Trade-Offs to Expect
- One SoC (AMP) versus two chips (dual-MCU or MCU + AP). Consolidating onto a heterogeneous SoC cuts board area, BOM, and integration cost; it also collapses two clean timing domains into one shared silicon with all the coupling this article describes. A dual-chip design like the dual-MCU railway BMU architecture on NXP S32K37xx + S32K1xx keeps the safety-monitoring domain physically isolated — the right call when the safety story does not tolerate shared silicon.
- Zephyr, FreeRTOS, or a vendor RTOS on the real-time core. Zephyr’s upstream OpenAMP support and its device-tree-based configuration keep the RTOS side close to the Linux-side conventions, which shortens integration. Vendor RTOSes (NXP FreeRTOS, TI SysBIOS/FreeRTOS, Xilinx FreeRTOS) ship with the vendor’s validated bring-up and are the pragmatic default when the schedule matters more than long-term portability.
- PREEMPT_RT versus stock Linux on the Linux side. PREEMPT_RT reduces Linux-side scheduling latency substantially and is the default when the Linux side also runs any soft-real-time work, but the achievable bound depends on the SoC, driver quality, and IRQ configuration. Stock Linux is simpler and often adequate when the RTOS-side does all the deterministic work.
- RPMsg with cacheable versus non-cacheable IPC buffers. Non-cacheable buffers avoid coherency traps and are the safe default; they pay a per-access DRAM round-trip that adds up under high message rates. Cacheable buffers with explicit cache maintenance are faster but require both sides to agree on ownership transitions — cheaper in cycles, more expensive in engineering to get right.
- Full peripheral partitioning versus shared with mediation. Assigning each peripheral exclusively to one OS is the cleanest design and the easiest to argue in a safety context. Sharing a peripheral through a mediator on one side is possible — for example, Linux owning the physical Ethernet and the RTOS reaching it through a virtual network device — but it puts the RTOS-side timing at the mercy of the mediator.
- OpenAMP versus a custom shared-memory IPC. OpenAMP with remoteproc and RPMsg is the upstream, portable option and integrates with Linux kernel system design cleanly. Custom shared-memory IPC can be faster and simpler for a fixed hardware target, at the cost of every future SoC change being an integration project.
Typical AMP System Engineering Tasks
IPC Contract and OpenAMP / RPMsg Integration
Ring sizing, back-pressure semantics, coherency model, kick-and-notify path with correct interrupt priority, and stress validation against burst-mode message rates rather than steady state.
Peripheral Partitioning and Boot-Time Ownership
Device-tree partitioning, SoC firewall / resource-domain-controller configuration, clock-tree ownership assignment across Linux and RTOS, and the M/R-core early-boot sequence that brings the RTOS side up before the Linux kernel takes the peripherals it does not own.
Cross-Domain Memory and Interconnect Analysis
LPDDR bandwidth budgeting across Linux and RTOS traffic, interconnect QoS configuration, cache-attribute layout for shared regions, and CMA / reserved-memory node design in the device tree — the subsystem where AMP determinism actually lives.
Real-Time Linux Configuration on the Target
PREEMPT_RT enablement, IRQ threading and priority map for the actual workload, isolcpus and cpuset partitioning, and evaluation of Linux-side worst-case latency on the target silicon rather than on the vendor evaluation kit.
AMP Bring-Up on Heterogeneous SoCs
NXP i.MX 8M Plus (Cortex-A53 + Cortex-M7), NXP i.MX 93 (Cortex-A55 + Cortex-M33), STM32MP2 (Cortex-A35 + Cortex-M33), TI AM64x (Cortex-A53 + Cortex-R5F), Xilinx Zynq UltraScale+ MPSoC (Cortex-A53 + Cortex-R5F + FPGA fabric) — bring-up of the real-time side with OpenAMP, integration into a Yocto build, and Linux + RTOS co-boot validated with the production power sequence. On real-time-only parts such as TI AM243x (Cortex-R5F, no application-processor Linux domain on-die), the same architectural questions apply but the split is naturally cross-chip, not intra-SoC.
You May Be Facing This If
- RTOS-side worst-case timing meets spec with Linux idle and misses spec when the Linux side runs its real workload for the first time.
- RPMsg round-trip latency drifts over hours or after a Linux OTA update, without any change on the RTOS side, and the reason cannot be pinned to a single subsystem without instrumentation.
- A peripheral “nominally owned” by the RTOS returns intermittent errors after a Linux-side firmware upgrade.
- Enabling PREEMPT_RT on the Linux side made the RTOS-side worst case worse, not better — or made no difference, because all the hard real-time work was already on the RTOS core.
- Memory-subsystem utilization on the target rises sharply under production workload and RTOS-side ISR times track that rise — an observation that has to be quantified per platform, not assumed against a fixed threshold.
- Two engineers cannot agree who owns the shared clock tree or the peripheral bus arbiter after a warm reboot.
- The AMP bring-up worked on the vendor evaluation kit and misses timing on your production hardware, and nobody has re-derived the worst case against your silicon revision.
Where AMP Integration Becomes a System-Architecture Problem
At this point the issue is not a setting on one operating system. It is the interaction between memory bandwidth, interconnect priorities, IPC contract, and peripheral ownership under conditions the OS documentation does not specify and the bench did not test.
In practice: budget the memory subsystem and interconnect load under both OSes running production workloads on the target silicon, engineer the IPC contract with an explicit coherency and back-pressure story, enforce peripheral partitioning in the device tree and the SoC firewall, and argue the RTOS-side worst-case bound against measurement on that target — not against an idle bench and not against a single tail-latency percentile. For control loops crossing the AMP boundary, this discipline sits alongside deriving the sensor-to-actuator response-time budget — the budget is the contract the AMP split has to hold.
For AI-in-the-loop products where perception and motion share the same heterogeneous SoC, the same pattern reappears one layer down — this is the ground deterministic motion loops for physical AI covers, where a model that meets its inference target on the benchmark and a controller that meets its cycle time in isolation both fail once inference, ROS 2 callbacks, and memory bandwidth compete inside the same timing budget.
Promwad Micro Proof
Programs where these questions come up most often — in Promwad’s experience — are industrial-controller designs migrating from a dual-chip baseline (MCU plus application processor on two boards) to a heterogeneous SoC on one board, robotics platforms combining perception with motion, machine-vision gateways where a real-time trigger sits next to Linux-hosted image processing, and HMI-plus-control consolidations where an operator interface and a control loop share a chip. The engineering competence Promwad brings to these programs — Linux BSP and kernel work, RTOS and bare-metal MCU firmware, SoC/MPSoC integration, industrial-controller and robotics architecture, and functional-safety-aware design — is what makes the cross-domain problems described above tractable, whether the split ends up intra-SoC, cross-chip, or a mix.
FAQ
When does an AMP architecture actually beat two separate chips?
Can I get bounded worst-case latency with Linux plus PREEMPT_RT and skip the RTOS?
What is OpenAMP and do I have to use it?
How do I stop Linux from stealing memory bandwidth from the RTOS core?
How is peripheral ownership actually enforced on a heterogeneous SoC?
Do I need functional safety certification if my AMP design controls actuators?
Which industrial SoCs are the pragmatic starting points for a new AMP design?
Related Engineering Cases
- Delta Robot Design for Conveyors (Jetson Orin Nano + Infineon XMC4800 + EtherCAT): Linux + RTOS on Jetson Orin Nano coordinating XMC4800-based servo drives over EtherCAT — an example of splitting the control loop across an application controller and dedicated drives.
- Universal Nvidia Robotics Platform with Industrial Protocols: Jetson perception host with the Hilscher netX communication controller carrying EtherCAT / PROFINET / EtherNet/IP as an independent timing domain over PCIe.
- Reusable Robotics Software Platform (EtherCAT + ROS 2 + 5G on Qualcomm RB3 + Hilscher netX 90): A reusable robotics stack packaged as a Yocto image, with motion control kept inside its own deterministic domain alongside ROS 2 and 5G on the application side.
- Dual-MCU Railway BMU Architecture on NXP S32K37xx + S32K1xx: A physically dual-MCU split rather than an AMP split — the right choice when the safety monitoring domain must not share silicon with the main controller.
- Structured Firmware QA for an Industrial Controller: Firmware QA process and Linux kernel workflow discipline on an industrial controller — the practices AMP designs rely on for reproducible bring-up.