IMPSPRGM · Fabric 2.0

Why a second stack

The first reference — SIM800C + STM8 — proved that two processors can share resources over a single board. It also exposed four systemic limits. Fabric 2.0 lifts the idea off one specific chip pair and turns it into a formalised runtime.

Generation 2 — two independent reference pairs

Generation 2 fixes one protocol (IFP/2) and one service model across two independent hardware stacks. That separates the application architecture from any particular modem or MCU vendor.

Stack architecture

Fabric 2.0 does not create hardware shared memory between chips. It virtualises remote resources as services — the network stack, storage, Bluetooth, GNSS, cryptography or a compute function.

1. Chip Profile. Static description of a node: chip family, transport endpoints, MTU, clocks, power states, reset path, available service providers.
2. Translator 2.0. Versioned RPC/event protocol: service ID, opcode, sequence, payload length, flags, CRC, ACK/NACK, timeout and idempotency.
3. Service Registry. An application requests a capability — net.socket, storage.object, ble.gatt, compute.math — never a vendor-specific modem API.
4. Transport Manager. Separates control and bulk traffic, chooses the physical transport, tracks credits and priority queues, and can fall back to UART.
5. Power Orchestrator. Never keeps the second node powered for a rare function: wake → service burst → checkpoint → sleep/off.
6. Recovery Supervisor. Tracks service liveness, invalidates stale handles, restarts the peer and restores session/state.

IFP/2 — the wire protocol

IFP/2 is the transport-neutral protocol that connects a deterministic control node (MCU) with one or more service-provider nodes (modem / OpenCPU / Linux gateway / compute node) without exposing vendor APIs to the application. Its rules are deliberately strict:

• UART/LPUART is the mandatory control-plane transport; USB may be negotiated for high-throughput bulk where both endpoints support it; SPI/SDIO stay optional adapters until individually qualified.
• Applications use service IDs and opcodes, never a vendor modem SDK call.
• Missing capabilities are never silently emulated — they are simply absent from CAPS.
• Remote resources are lease-based; stale handles are invalidated on session loss, and non-idempotent operations are never blindly replayed after recovery.
• The control MCU keeps a local degraded mode for safety and metrology even when the peer is unavailable.

Frame format · fixed 20-byte header

The tail carries the payload (0…65535 bytes) and a PAYLOAD_CRC32. Multibyte fields are little-endian. On UART the frame is wrapped as COBS(frame) + 0x00; on USB the raw frame is used, relying on endpoint boundaries.

Frame types, flags and services

0x01 HELLO      0x02 CAPS
0x03 SELECT     0x04 READY
0x10 RPC_REQUEST
0x11 RPC_ACK    0x12 RPC_RESULT
0x13 EVENT      0x20 HEARTBEAT
0x21 LEASE_RENEW
0x30 BULK_OPEN  0x31 BULK_DATA
0x32 BULK_CLOSE 0x7F ERROR

0 ACK_REQUIRED
1 IDEMPOTENT
2 URGENT
3 ENCRYPTED
4 MORE_FRAGMENTS
5 BULK_REFERENCE
6 RETRY
7 reserved

0x0001 SYSTEM  0x0002 HEALTH
0x0003 POWER   0x0010 TIME
0x0020 LOG     0x0100 NETWORK
0x0101 SOCKET  0x0102 MQTT
0x0103 HTTP    0x0110 SMS
0x0120 GNSS    0x0200 STORAGE
0x0300 BLUETOOTH 0x0400 CRYPTO
0x0500 COMPUTE 0x0600 FOTA

Service-ID ranges: 0x0000–0x0FFF IMPSPRGM core · 0x1000–0x7FFF standardized extensions · 0x8000–0xBFFF vendor-specific · 0xC000–0xFFFF experimental. Every service may implement the common opcodes GET_CAPS / GET_STATUS / CONFIGURE / START / STOP / RESET.

↓ IFP/2 Reference SDK & firmware — Release v1.0   ↓ IFP/2 Specification v1.0 (PDF)

Boot & capability negotiation

1. CONTROL_NODE -> HELLO(proto_version, node_id, supported_transports, max_frame)
2. PEER         -> CAPS(service_catalog, versions, MTU, power_modes, security)
3. CONTROL_NODE -> SELECT(control_transport, bulk_transport, QoS, heartbeat)
4. PEER         -> READY(session_id, credits, heartbeat_period, lease_defaults)
5. Both sides create service leases.
6. The application starts only services actually discovered at runtime.

RPC and bulk transfer

request = { version, service_id, opcode, sequence,
            flags /* ACK_REQUIRED, IDEMPOTENT, BULK_REFERENCE… */,
            payload_length, payload, crc }

Client -> enqueue by priority -> transmit -> ACK -> async RESULT / EVENT
Timeout -> retry if IDEMPOTENT
        -> otherwise query transaction status
        -> escalate to Recovery Supervisor if the peer is unresponsive

Large objects never block control commands: the control plane stays on UART/LPUART while a bulk object is streamed in segments over the best shared transport, with credit-based flow control so a slow receiver cannot overflow buffers. On transport failure the transfer resumes or restarts on the fallback UART per policy.

Automatic recovery

The heartbeat checks not only "is the processor alive" but the lease of each remote service. After a fault, stale handles are invalidated immediately — the application never keeps working against a phantom resource.

• SUSPECT — freeze creation of new remote handles.
• ISOLATE — invalidate all remote leases/handles from the lost session.
• RECOVER_PEER — service restart → runtime restart → hardware reset → power-cycle, per board capabilities.
• RENEGOTIATE — a fresh HELLO/CAPS/SELECT/READY session.
• RESYNC — restore only journaled/idempotent state.
• DEGRADED — retain local measurement, archive, safety and control logic when the peer cannot be restored.

Baseline timeout profile

Generation-2 baseline values for bench qualification. They may be tuned without changing the wire protocol.

True deep-sleep uses an expected wake time / lease deadline instead of a periodic heartbeat.

Independence from Embedded AT

Universality therefore comes not from a specific vendor's EAT, but from having at least one adapter able to satisfy the required service contract.

References & validation plan

SIM800C + STM8 remains the legacy reference. The next references specifically test portability, high throughput and automatic recovery.

Practical effect for autonomous telemetry

• Lower BOM. Export a resource from an already-installed processor instead of adding a separate flash / Bluetooth / crypto device — only when the capability is actually available.
• Longer battery life. The Power Orchestrator batches remote calls, minimises the communication node's wake time, and keeps the local control loop alive.
• Faster migration. Swapping 2G for LTE, or an 8-bit MCU for a 32-bit one, changes adapters and the chip profile — not the application service model.

Technical basis

The architecture relies on publicly documented capabilities of existing platforms; the exact capabilities are always defined by the chosen model and its SDK. No vendor-specific API reaches the application layer — it ends inside the Provider Adapter. That is the core contract of Fabric 2.0.

• SIMCom SIM800 series — Embedded AT, serial port, CMUX multiplexer, TCP/IP, SMS, filesystem (legacy reference).
• Quectel EC200U / EG915U — LTE Cat-1 bis M2M/IoT modules with rich interfaces and USB support (modern reference candidates).
• ST STM32U5 — Cortex-M33 with FPU, DMA/LPBAM, multiple SPI/USART and USB — a convenient 32-bit low-power MCU for fast-transport and autonomy checks.
• Companion article — IMPSPRGM · Interprocessor OS (the Generation-1 three-bus runtime this work generalises).

Licensing & Intellectual Property

IMPSPRGM™ is proprietary technology of LLC IMPSPRGM (Tashkent, Republic of Uzbekistan). The technology — including the reference firmware, the Translator mechanism, the IFP/2 protocol, the provider-adapter model and the supporting design files — is distributed exclusively under a written Licence Agreement on a per-unit (per-device) basis. Source code, architectural diagrams and the protocol remain the sole property of LLC IMPSPRGM; reverse engineering, redistribution and derivative works require prior written consent.

Commercial inquiries and per-unit quotations: impsprgm@umail.uz

← Interprocessor OS   Back to home