Communication System and EV-MUX

[中文]

This chapter follows the complete ESP-VISION host communication path: MicroPython I/O, ESP-IDF logs and camera data, physical interfaces, session ownership and framing, through the shared Device Core SDK to IDE, Agent, CLI or custom host applications. It describes the current EV-MUX v4 implementation; firmware release, session version and wire format are separate concepts.

Important

evMuxVersion:4 defines session/authorization behavior; EVMUX/1 defines byte framing. v4 still uses EVMUX/1: do not change the header to EVMUX/4. IDE 1.3.0 Device Core accepts only explicitly v4-compatible firmware.

The complete path at a glance

Figure 1: Output is classified, ownership-scoped and framed before reaching one physical connection. Host commands travel in reverse through parser, authorization and REPL/control dispatch. Keep reading because responses, text and images can interleave.

Recommended reading order

• Architecture, Execution Contexts and Standard I/O
• Physical interfaces, connection generations and build configuration
• Session ownership, acquisition and recovery
• Frame format, logical channels and RPC protocol
• Interactive Python, scripts and file operations
• Preview, debug capture, backpressure and statistics
• Host integration, Wi-Fi configuration and recovery
• LAN discovery protocol and board defaults
• Device Core integration guide
• Communication acceptance, closed-loop tests and troubleshooting

Find the relevant topic

Question	Entry point
How do Python print, C printf and IDF logs differ?	Architecture, Execution Contexts and Standard I/O
What are the two USB interfaces, UART and Wi-Fi/TCP?	Physical interfaces, connection generations and build configuration
How do competing hosts, disconnects and resets recover?	Session ownership, acquisition and recovery
How do I implement framing and RPC?	Frame format, logical channels and RPC protocol
How do I input Python, transfer files and run long scripts?	Interactive Python, scripts and file operations
How do preview and debug.capture_frame differ?	Preview, debug capture, backpressure and statistics
How do I provision Wi-Fi and handle startup data?	Host integration, Wi-Fi configuration and recovery
How do I install Device Core and integrate serial/TCP, files and preview?	Device Core integration guide
How do I prove completion and diagnose failures?	Communication acceptance, closed-loop tests and troubleshooting

Six distinct concepts

• Physical interface / sink: backend type, for example usj or tcp.

• link: one exact connection with backend, slot and generation; reusing a TCP slot still creates a new link.

• stream: internal user/debug routing groups, not eight independent serial ports.

• channel: frame semantics, for example repl.stdout or preview.frame.

• sessionId: ownership credential tied to an exact link; it cannot move to another socket.

• vmEpoch: MicroPython generation. A surviving session does not preserve old-VM work.

Current implementation boundaries

There is at most one session owner holding both streams. Other links can discover the device, but cannot run a second independent control session. Acquisition contention and explicit handoff are supported; forced eviction of a valid owner is not.

TCP is a raw STA IPv4 byte server on default port 3232 with at most two accepted links. It is not HTTP, WebSocket or MicroPython WebREPL and does not add authentication/encryption in this version. Browsers use a host-side byte bridge: see Host integration, Wi-Fi configuration and recovery.

ROM download and EV-MUX runtime are separate protocol phases. The MicroPython REPL remains the interpreter console; IDF system console carries early initialization, ROM/bootloader and some fatal output. Raw text at these boundaries is not a valid business frame.