Nationz Open-Sources N32H787 Edge AIoT Design: NOMMU Linux and WeniClaw on an MCU Board Turn a WeChat Message into On-Device Person Detection, Snapshot and Lighting Control

On November 6, Nationz Technologies (300077.SZ, 02701.HK) open-sourced an edge AIoT reference design built on its N32H787 high-performance MCU. The board is an MCU-class platform running Linux with an on-board execution framework called WeniClaw: a user sends a natural-language instruction over WeChat, and the device performs person detection, takes a colour photo and controls lights locally, closing the sense-decide-act loop on the device while the cloud is left with one job — turning language into an action intent.

Division of labour: the cloud supplies intent, the device keeps the judgment

In the demonstration, the user asks whether anyone is present and, if so, to take a colour photo. The board runs lightweight person detection locally, captures a frame and sends it back. Nationz frames the value in four points: with external memory and storage added, the hardware bill of materials stays MCU-class, which matters for volume deployment; detection and scheduled tasks keep running when the network drops, and the system can be recovered on site, which suits unattended installations; video never leaves the device, with only a single frame uploaded when something worth looking at is detected, cutting traffic cost and compliance exposure; and the interface is WeChat itself, so no app is needed and a new capability is a document dropped onto the board rather than a firmware rebuild.

The last of those four is easily read as a convenience detail. It is really about delivery: integrators and solution providers without an embedded team can modify the board and its documentation instead of writing drivers and a network stack from scratch.

The actual technical bet: Linux on a Cortex-M7 with no MMU

AI on an MCU is not novel. What is unusual is the contents of the repository. The NSING-Community/n32h7xx_linux workspace describes itself plainly: an ARMv7-M NOMMU kernel, a CM7 bootloader, a BusyBox rootfs and a uClibc FDPIC toolchain, with the project's own code under BSD-3-Clause (the Linux kernel remains GPL-2.0-only, and the ns-flash programming tool is closed). The N32H787_HMI_V1.1 reference board carries 32 MiB of SDRAM, roughly 2 MiB of on-chip Flash used only for the bootloader, and a 16 MiB SPI NOR device partitioned into dtb, kernel, rootfs and system. The root filesystem is a 3 MiB read-only SquashFS; system is a writable JFFS2 partition that survives kernel and rootfs updates.

Why NOMMU Linux rather than bare metal or an RTOS? Because the Cortex-M7 has an MPU and no MMU, so Linux runs its NOMMU branch: processes, threads, filesystems and networking are present, but each process cannot be given its own virtual address space. The project's own README lists the costs — large allocations usually need physically contiguous memory, and repeated allocation and release produces the familiar "plenty of free memory in total, but the large request fails" condition; without MMU-based isolation, an out-of-bounds access can affect other programs or the kernel, so multiple processes do not amount to reliable security isolation. What comes back is reuse: Linux drivers, network protocols, SSH and curl, a shell and a large body of open C and C++ software, recompiled for the target rather than rewritten.

That trade-off defines the addressable work: fixed-function networked controllers, data-acquisition terminals, protocol converters and lightweight gateways with predictable memory needs. It excludes desktop-class browsing, large databases, local LLM inference and multi-tenant services that depend on hard process isolation. The README states the caveat without softening it: compiling successfully does not mean the code will boot and run stably on the board over time.

What the N32H787XIB7 brings

The XIB7 is a representative part of the N32H78x family. According to the datasheet and product page:

• Heterogeneous dual core: a Cortex-M7 main core at 600MHz and 1284 DMIPS, plus a Cortex-M4F auxiliary core at 300MHz and 375 DMIPS — 1659 DMIPS combined by the family's own figure. The M7 carries a double-precision FPU, DSP instructions and 32KB instruction plus 32KB ECC data cache.
• Memory: 2048KB on-chip Flash in this variant (4096KB in others), 1504KB SRAM (1024KB TCM, 480KB system, 4KB backup), with SDRAM expansion.
• Graphics and imaging: a 2.5D GPU with a 300-megapixel-per-second fill rate supporting scaling, rotation, blending and anti-aliasing; a hardware JPEG codec; two DVP camera interfaces up to 1280×720 at 30fps; an LCD controller to 1920×1080 and MIPI-DSI.
• Connectivity: ETH1 at 10/100/1000M and ETH2 at 10/100M, both with IEEE 1588; eight CAN-FD channels; seven SPI (50MHz), ten I2C (3.4MHz), xSPI and SDRAM at 133MHz, FEMC and two SDMMC interfaces.
• Security and industrial ratings: hardware acceleration for AES/TDES, SHA and SM4, plus TRNG, encrypted storage and secure boot; -40°C to +105°C, 2.3V to 3.6V, LQFP176 and TFBGA240+25 packages, up to 168 GPIOs.

Set that against the software stack and the design makes sense. Linux needs memory capacity and peripheral completeness; vision needs DVP, JPEG and graphics acceleration; networking needs Ethernet plus TLS. The silicon has all three. What was missing was someone assembling the stack and publishing it.

How much is actually open

More than source code. Prebuilt images sit in bin/, and a single make produces the bootloader, kernel, rootfs and a full SPI NOR image; make CAMERA=1 adds OV5640 camera support, and make LCD=0 disables the LCD and GPU and returns 3 MiB of graphics memory. Updates have three paths: applications and libraries go to the writable /system over scp or adb push, dtb, kernel and rootfs go over SSH-based network OTA, and the bootloader is written to on-chip Flash with a CMSIS-DAP probe.

Several optional components map directly onto the demo. WeniClaw is a 253KB ARM FDPIC binary that calls an OpenAI-compatible endpoint for the model and pairs with WeChat through Tencent's iLink Claw channel, shipping with five skills: photo capture, person detection, record and playback, GPIO, and storage location. human-detect performs 320×240 greyscale person-position detection on the board with MJPEG preview, colour snapshots and a browser dashboard showing frame rate and inference time. Neither is in the default image; both live on the writable /system partition and survive kernel and rootfs upgrades.

One detail belongs up front: on first run WeniClaw opens a configuration page on port 80 with no login, and the documentation instructs users to work on a trusted network and finish quickly. The model token and WeChat pairing state land on /system. Defaults that prioritise getting the thing running must be tightened before anything ships.

Use cases and the market frame

The published scenarios fall into three groups: unattended sites such as PV plants, energy-storage cabinets and charging piles, where the device detects anomalies locally and reports on demand; privacy-sensitive settings such as home care and elder care, where video stays on the device; and industrial or agricultural work — line-side station inspection, equipment status alarms, livestock inspection, smart-city edge nodes — where MCU-class cost replaces an industrial PC.

For market context, Nationz cites Yole Group's expectation that AI-capable MCUs will account for at least 10% of all MCUs by 2028, with the global MCU market exceeding USD 34 billion by 2030 at roughly 6% CAGR from 2024 to 2030. ABI Research projects global TinyML device shipments rising from about 15 million units in 2020 to 2.5 billion in 2030. Through 2026, TI and other international vendors have also introduced edge-AI MCU products. The numbers describe gradual volume growth rather than substitution: edge AI arriving in MCUs is a product-line evolution, not an architectural revolution.

Boundaries worth stating

The repository calls itself an experimental project: features and interfaces may change, and it has not been through full product-grade stability, reliability or security validation, so anyone taking it into a product must qualify it themselves. The reference board's Ethernet is RMII at 100Mbps full duplex, which is not the SoC's gigabit capability, so video workloads must be budgeted against the board as built. And the fragmentation and isolation limits of NOMMU do not disappear when another SDRAM part is soldered down; long-running stability has to be designed in with streaming, small buffers and reused memory. Put those three beside the one-line demo and the selection picture is complete.

HSY Perspective

The significance of this release is not AI on an MCU; it is moving an edge device's software stack from bare metal to Linux — which changes an integrator's engineering budget, not a chip's benchmark score. What the repository hands over is an ARMv7-M NOMMU kernel, a BusyBox rootfs, a uClibc FDPIC toolchain, SSH, curl and network OTA: all mature on application processors, and never before available as an organised public reference on an MCU. For a solution provider without an embedded team, the saving is not the algorithm but the network stack, filesystem, remote update path and debug channel — historically the most person-month-hungry parts of the job, and the parts that never appear in a datasheet.

A directional judgment follows. Competition in this class will shift from clock rate and DMIPS to the completeness of the board support package: are the drivers there, can updates be done remotely, is there user-space software to link against. Publishing kernel, toolchain, images and five peripheral skills at once moves the comparison from the spec table to engineering usability. Yole's 10%-by-2028 figure points the same way — demand grows as installed equipment is replaced, not in a single substitution wave.

The boundary is equally clear. Without an MMU there is no per-process address-space isolation, and fragmentation will eventually produce the "enough free memory in total, but the large allocation fails" condition; the documentation itself labels the project experimental. Within those limits it fits networked vision terminals with fixed function and predictable memory. Once the workload becomes multi-tenant isolation, local LLM inference or complex memory mapping, the MCU-class path hits its wall, and adding memory does not fix it — an application processor with an MMU is the correct answer.

Sources: Nationz Technologies, "Edge AI comes to MCUs: Nationz open-sources an edge AIoT design" (November 6, 2026); NSING-Community/n32h7xx_linux repository README (BSD-3-Clause) and the N32H787 series datasheet; Yole Group and ABI Research projections as cited in the Nationz release.