Feature: Processors and MCUs


processor), Cortex-M55 and Cortex-M33 processors, an Ethos-U55 NPU, plus additional dedicated low-power neural- network acceleration. Other devices make different trade-offs: The STM32N6


by STMicroelectronics, for example, has no embedded user Flash and instead uses immutable Boot ROM to bootstrap executable firmware from external memory. The important trend is therefore not necessarily that RRAM


replaces Flash. It is that bulk application storage is moving off-chip, while limited on-chip non-volatile resources are reserved for the functions that genuinely need them.


Making room for more processing estate Once a large Flash array is removed, silicon area can instead be devoted to SRAM and increasingly sophisticated processing and peripheral functions. This is particularly important for Edge AI, as hardware audio and vision accelerators can replace software-only pipelines. While a conventional MCU application may be satisfied


with a few hundred kilobytes of SRAM, vision processing, neural-network inference, graphics and sophisticated communications demand megabytes. Large internal SRAM also offers deterministic, high-bandwidth access that is difficult to reproduce using external serial memory. PSOC Edge E84, for example, divides processing


between two principal CPU domains. A low-power Cortex-M33 running at up to 200MHz handles system control, communications and security-related tasks, while a Cortex-M55 running at up to 400MHz provides the high- performance application processor. The M55 incorporates Arm’s Helium vector extensions and is partnered with an Ethos-U55 neural processing unit. This heterogeneous architecture lets developers match workloads to processors rather than simply running everything on one increasingly fast CPU. An always-on detection algorithm might run on the low-power domain, for example, waking the Cortex-M55 and NPU only when more substantial processing is required. The result occupies an interesting position between the traditional microcontroller and an applications processor: much of the performance and peripheral sophistication of the latter, but with the deterministic behaviour, low-power characteristics and RTOS-orientated programming model expected from Cortex-M-based microcontrollers.


Multiple processors mean multiple applications There is a software consequence to all this hardware. A multicore MCU is not necessarily one application executing on several equivalent processors; different cores may have different instruction sets, security states, memory visibility and responsibilities. On PSOC Edge, for example, the Cortex-M33 acts as the


system processor that provides ‘platform’ services to the main application that is designed to run on the Cortex-M55. The M55 is complemented by the Ethos-U55 NPU that provides


very high-performance inference for ML algorithms. The device also contains a completely separate Secure Enclave which is used to provide a secure boot and optional run- time security services, to support interworking of the two processors hardware inter-processor communication (IPC) channels, and provide signalling and data exchange between the execution domains. These mechanisms generally map well onto familiar RTOS concepts: an IPC interrupt can ultimately cause a task to wake, with software presenting received information through queues, mailboxes or similar RTOS features. The resulting system might therefore resemble a compute platform as shown in Figure 1:


Figure 1: Multi processor platform


Where does the code live? With large internal Flash gone, application firmware normally resides in external non-volatile memory. High-speed serial NOR connected through Quad or Octal SPI is a natural choice. Modern serial interfaces can be memory mapped into the processor address space, allowing code to execute directly from external memory. This is typically known as execute-in- place, or XIP; see Figure 2:


Figure 2: XIP (eXecute In Place) Flash memory However, performance depends on interface bandwidth,


latency, cache behaviour and the locality of instruction accesses. For performance-critical code, another option is load-and-run from Internal SRAM; see Figure 3:


Figure 3: Memory loader/bootloader and SRAM execution www.electronicsworld.co.uk October 2026 21


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44