Applies to CPU-ESPS3-X1, CPU-ESPS3-X2, and CPU-ESPS3-X3
The NORVI X CPU module is the brain of the NORVI-X modular industrial IoT controllers. All three CPU variants (X1, X2, X3) share the same core hardware for on-board I/O, display, Ethernet, and RS-485. The main difference between the NORVI X1, X2, and X3 is their cellular communication capability. The X1 does not include a cellular modem, while the X2 uses the SIMCOM A7672G modem to provide 2G/4G connectivity. The X3 uses the EC25 modem, providing 4G LTE connectivity for global network support. Everything below applies equally to all three unless a section says otherwise.
The CPU Module in Context #
Every NORVI X CPU is built around an ESP32-S3-WROOM-1U-N16R2 module, giving you 16MB of flash, 512KB of SRAM, and 2MB of PSRAM to work with. The CPU itself does not carry field I/O such as digital inputs or relay outputs. Instead, it exposes a 50-pin expansion port on the bottom of the housing, and you snap on the expansion modules you need (digital input, relay output, transistor output, analog I/O, thermocouple, RTD, and so on) to build the exact controller your application calls for. Think of the CPU module as the central processing and communication unit, while the expansion modules provide the interface for connecting and interacting with field devices and wiring.
The On-Board Display #
Each CPU module has a built-in 2.0 inch TFT display with a resolution of 240 by 320 pixels and a resistive touch layer, driven by the ST7789 controller. The display communicates with the ESP32-S3 over SPI, and the touch controller shares the I2C bus.
| Signal | GPIO | Purpose |
|---|---|---|
| MOSI | IO11 | SPI data to the display |
| MISO | IO13 | SPI data from the display |
| SCLK | IO12 | SPI clock |
| DIS_CS | IO45 | Display chip select |
| DIS_DC | IO46 | Display Data / command select |
| TP_RST / DIS_RST | IO47 | Touch panel and display reset |
| Touch SCL | IO9 | I2C clock for the touch controller |
| Touch SDA | IO8 | I2C data for the touch controller |
Front Panel Buttons and Indicators #
Two physical buttons sit on the front face of every CPU module, alongside a RUN and an ERROR LED. None of these are wired directly to ESP32-S3 GPIOs. Instead, they are all routed through a I2C IO expander mounted on the board.
| Function | Expander Pin | IO Expander |
|---|---|---|
| Button 1 | P0 | PCA9536, I2C address 0x41 |
| Button 2 | P3 | |
| RUN indicator | P2 | |
| ERROR indicator | P1 |
microSD Card Slot #
All three CPUs include a microSD slot for local data logging and firmware-related storage. The microSD card communicates with the CPU through the shared SPI interface using the following signals:
| Signal | GPIO |
|---|---|
| CS | IO42 |
| MOSI | IO11 |
| MISO | IO13 |
| SCLK | IO12 |
| Card detect | Not connected |
Built-In Ethernet #
All three CPUs have built-in wired Ethernet in addition to Wi-Fi 2.4GHz and Bluetooth. The Ethernet controller connects to the ESP32-S3 over the same shared SPI bus used by the display and microSD card (MOSI IO11, MISO IO13, SCLK IO12), plus three dedicated control lines of its own:
| Function | GPIO |
|---|---|
| Chip select (SCSN) | IO1 |
| Reset (RSTN) | IO2 |
| Interrupt (INTN) | IO4 |
The dedicated CS, reset, and interrupt lines allow the CPU to communicate with the Ethernet controller independently on the shared SPI bus. These lines are used for device control, not for transferring data, so Ethernet, the display, and the SD card still share the available SPI bandwidth when operating at the same time.
RS-485 #
All three modules provide one built-in RS-485 port, operated half-duplex with automatic direction (flow) control - the transceiver switches between transmit and receive automatically, so no manual DE/RE toggling is needed in firmware.
| Parameter | X1 / X2 / X3 |
|---|---|
| Transceiver IC | SN65HVD72DGKR |
| TX pin | IO15 |
| RX pin | IO16 |
| Unit load | 1/4 |
| Duplex mode | Half-duplex |
| Direction control | Automatic |
Addressing Basics #
Working with the on-board I/O touches three distinct addressing layers: I2C addressing inside the CPU module, RS-485 (Modbus RTU) addressing on the field bus, and IP addressing on Ethernet. Each solves a different problem, but the last two connect directly once Modbus is layered onto Ethernet - covered below.
I2C addressing on the CPU #
The front-panel buttons, RUN and ERROR LEDs, and the touch controller all share the same I2C bus (SDA on IO8, SCL on IO9). Because several chips sit on one bus, each one needs its own fixed address so the ESP32-S3 knows which chip it's talking to. The button and LED expander answers at address 0x41. When an expansion module is attached, its chip-select lines are also handled through I2C, via a PCA9539 expander at address 0x75 on the expansion port. As long as every device on the bus has a distinct address, all of them can share the same two wires without conflict.
RS-485 (Modbus) addressing on the field bus #
RS-485 is a multi-drop bus: multiple field devices share a single pair of wires. To distinguish between them, every device on the segment - including the NORVI CPU itself when acting as a Modbus slave - is assigned a unique node address (Modbus slave ID), typically in the range 1-247.
- A Modbus master issues a request containing a target address.
- Only the device matching that address responds.
- Every device on a given RS-485 segment must have a different slave ID before commissioning.
Ethernet / IP addressing - and where it meets Modbus #
The Ethernet port introduces a third, independent addressing layer, required whenever the CPU communicates over a LAN.
IP Addressing #
The CPU requires a standard network identity to participate on Ethernet/TCP-IP:
- IP address (static or DHCP-assigned)
- Subnet mask
- Gateway
On its own, this is a different concern from I2C or RS-485 addressing - it's what lets the device be reached on the network at all. But the moment the CPU exposes Modbus over Ethernet (Modbus TCP) instead of, or alongside, RS-485 (Modbus RTU), IP addressing becomes the device-identification method for Modbus too, and the addressing model shifts:
| Aspect | Modbus RTU (RS-485) | Modbus TCP (Ethernet) |
|---|---|---|
| Device identification | Slave ID on shared wire | Target IP address (connection-based) |
| Default port | N/A | 502 |
| Unit ID role | Primary addressing method | Often fixed (e.g., 1 or 0xFF); mainly used for backward compatibility or RTU bridging |
| Register map | Same | Same |
- A Modbus TCP master opens a connection directly to a specific IP:port, so the connection itself identifies the target device.
- The Unit ID field is still present in the Modbus TCP frame, primarily for compatibility or when a TCP-to-RTU gateway bridges onto an RS-485 segment behind that IP.
- The register map (holding registers, coils, etc.) is identical regardless of transport RTU or TCP.
