Wiznet makers

Thumbnail Image: AI-generated image

📌 Overview

ZonalArchECU_W_SomeIP is a scale-model zonal ECU prototype that explores how a modern vehicle-style zonal architecture can be implemented on a small platform. According to the repository, the system is built around two zonal ECUs (front and rear), one central switch, and one central computing unit (CCU). The zonal ECUs are intended to handle local motor control and sensing, while the CCU is responsible for high-level behavior such as path planning.

What makes this project stand out is that Ethernet is treated as the backbone of the architecture, not just as an extra interface. The public materials clearly position the system as a layered zonal network, where local ECUs are separated from centralized compute and linked through a switch-based communication fabric. In that context, the W5500 is not merely a connectivity chip — it is the hardware link that allows an ESP32-based zonal node to behave like a networked ECU.

AI-generated image

SOME/IP is an AUTOSAR-defined automotive Ethernet protocol. Its concept is service-oriented communication over IP. It is used when ECUs need to exchange software functions and data as network services. Its role is to provide remote procedure calls, event notifications, and serialized inter-ECU communication.

A zonal ECU is not a protocol but an area-based vehicle controller. Its concept is to group sensors and actuators by physical vehicle zone instead of by isolated function. It is used when a vehicle architecture connects many local devices in one zone to a central compute ECU. Its role is to provide local I/O aggregation, data and power distribution, and a network connection between the zone and the central compute unit.

In this repository, the front and rear nodes are treated as zonal ECUs, while the CCU handles higher-level control through an Ethernet backbone built around the W5500 interface.

📌 Features

Scale-model zonal vehicle architecture
The repository explicitly presents the prototype as a zonal architecture with a CCU, a communication layer, zonal ECUs, and a sensor/actuator layer. This makes it more than a simple robotic car controller.

Dedicated W5500 Ethernet module
The project includes a full EthernetW5500 subsystem with custom SPI transaction framing, register definitions, payload buffers, helper functions, and a dedicated runtime service task.

Motor-control service already integrated
A separate H-bridge service manages local motor control, exposing safe set/get functions and a task loop that continuously applies pending updates. That gives the zonal node a real local actuation role.

Static network bootstrap for deterministic bring-up
The public snapshot defines a fixed gateway, source IP, subnet mask, MAC address, and a SOMEIP_PORT constant. This is a practical prototype choice for repeatable bring-up and early debugging.

Linux/Ubuntu host development workflow
The visible project metadata suggests that development is being done on a Linux/Ubuntu host with ESP-IDF 6.1.0 and the xtensa-esp32-elf-gcc toolchain. This matters because the project is not a native Ubuntu application — it is an ESP32 firmware project developed from a Linux workstation.

📌 System Architecture

AI-generated image

The readme describes the design in four layers: Central Layer, Communication Layer, Zonal Layer, and Actuators & Sensors Layer. At the top sits the CCU, which handles path planning and overall behavior. The central switch sits below it and forwards packets between compute and the zones. Then come the front and rear zonal ECUs, which act as local gateways to the actual motors and sensors mounted on the vehicle model.

That is exactly the key idea behind zonal E/E architecture: instead of scattering separate ECUs across every function, the system groups electronics by physical zone, then links those zones over Ethernet. Even on a small model, the project is clearly trying to mirror that industry direction.

The firmware layout reflects this architectural split. On startup, app_main() calls AppInit(), which launches separate services including MotorCtl and EthernetAdapterCtl. This means the zonal ECU is already structured as a multi-service node rather than as a single control loop.

📌 Development Environment and Runtime Context

One detail worth making explicit is the difference between the development environment and the runtime target.

This project appears to be developed on a Linux/Ubuntu host. The VS Code configuration points to /home/fus/esp/..., uses an ESP-IDF toolchain, and targets xtensa-esp32-elf-gcc. The generated sdkconfig also confirms ESP-IDF 6.1.0 and CONFIG_IDF_TARGET="esp32".

So the most accurate description is:

• Host development environment: Ubuntu/Linux
• Runtime environment: ESP32 firmware on ESP-IDF + FreeRTOS

That distinction matters because the project may be developed from Ubuntu, but the actual ECU logic runs on the ESP32, not on the Linux machine.

📌 Role and Application of the WIZnet's Chip

AI-generated image

WIZnet chip used: W5500

In this project, the W5500 is the Ethernet backbone interface for the zonal ECU node. It allows the ESP32-based controller to join the prototype’s Ethernet network and communicate as part of the zonal architecture described in the repository. Without it, the board would remain only a local control unit; with it, the node becomes part of the larger vehicle-style communication fabric.

The public implementation is quite low-level and therefore especially informative. The project defines its own packed SPI transaction headers, its own common/socket register mappings, and its own read/write helpers for the W5500. During initialization, it writes the gateway address, subnet mask, source IP, and source MAC directly into the W5500 common registers.

That design choice tells us something important about the communication stack.

What communication path is actually used?

lwIP is enabled at the project level, because the ESP-IDF configuration includes CONFIG_LWIP_ENABLE=y and CONFIG_ESP_NETIF_TCPIP_LWIP=y.

However, the visible W5500 path does not appear to run through lwIP or ESP-IDF’s esp_eth layer. Instead, the public code directly drives the W5500 over SPI and manipulates its internal registers and socket state.

Is this MACRAW mode?

Based on the startup documentation, no.
The public W5500 startup sequence explicitly shows:

• interrupt setup and RAM allocation for Socket 0
• Sn_MR set to UDP mode (0x02)
• local port assignment
• OPEN command execution
• expected SOCK_UDP socket status

That means the visible path is not MACRAW mode. It is closer to a direct W5500 hardware UDP socket bring-up flow.

Does it use the W5500 hardwired TCP/IP engine?

Yes — that is the most accurate interpretation of the public snapshot.
The code is directly configuring W5500 common and socket registers, allocating socket buffers, and preparing Socket 0 for UDP communication. That is exactly the kind of usage model associated with the W5500’s hardwired TCP/IP / socket engine, even though the visible implementation currently centers on UDP setup rather than a full higher-layer protocol stack.

Does it use WIZnet’s official socket library?

In the public repository snapshot, it does not appear to use WIZnet’s standard ioLibrary.
There is no visible wizchip_conf.h, socket.h, or the usual ioLibrary file layout. Instead, the project provides its own EthernetW5500.c/.h and EthernetW5500Cmds.h, which strongly suggests a custom low-level W5500 driver rather than a wrapper around WIZnet’s standard socket library.

So, the cleanest summary is:

• Host development: Ubuntu/Linux
• Runtime target: ESP32 + FreeRTOS
• Project-level TCP/IP stack: lwIP enabled
• Visible W5500 path: custom SPI/register driver
• Mode: not MACRAW
• Likely communication approach: direct use of W5500 hardwired UDP socket flow
• WIZnet ioLibrary: not visibly used in the public snapshot

📌 Market & Application Value

The clearest value of this project is as a research and prototyping platform for zonal automotive networking concepts.

For students, labs, and embedded developers, this project provides a small-scale way to explore how Ethernet-based zonal ECUs might be structured without immediately moving to full-size automotive hardware. The layered system diagrams, explicit W5500 startup sequence, and separated motor/network services make it a useful learning example for modern vehicle E/E architecture.

It also has practical value as a prototyping framework. Many small robotic or mobility models remain function-centric, with isolated boards connected by ad hoc logic. This prototype instead asks what happens when you treat the platform more like a vehicle, with a compute node, a central switch, and zone-level ECUs connected through Ethernet. That makes it relevant not only to scale-model cars, but also to academic mobility platforms, robotics networking experiments, and service-oriented ECU research.

At the same time, the public code still looks like a work-in-progress engineering prototype rather than a complete end-to-end SOME/IP demonstration. The communication direction is clear, but the visible implementation is strongest today as a zonal ECU backbone prototype with motor control and W5500 bring-up already in place.

📌 External Indicators

The repository includes both logical and physical architecture diagrams, which is a positive sign that the author is thinking at the full-system level, not only at the code level. The docs folder also contains a dedicated W5500 startup sequence in Mermaid format, which is especially helpful for understanding how the network node is supposed to boot and enter UDP communication mode.

There is also a small Python ARP test script that repeatedly probes the ECU IP address. That suggests the author is actively validating Ethernet visibility and network presence during bring-up.

📌 Summary

ZonalArchECU_W_SomeIP is a scale-model zonal ECU project that explores how a vehicle-style zonal architecture can be implemented with front/rear ECUs, a central switch, and a CCU. The public code already shows real motor control, a structured FreeRTOS service model, and a substantial custom W5500 Ethernet subsystem.

A key technical takeaway is that this project is developed on an Ubuntu/Linux host but runs as ESP32 firmware, and the visible W5500 path is not MACRAW and does not appear to use WIZnet’s standard socket library. Instead, it uses a custom low-level SPI/register driver to access the W5500’s hardwired socket engine, with the current public snapshot showing a UDP-oriented bring-up flow that appears to be laying the groundwork for future SOME/IP-style communication.

📌 FAQ

Q1. Does this project run on Ubuntu?
Not as a runtime application. It appears to be developed on Ubuntu/Linux, but the actual runtime target is ESP32 firmware built with ESP-IDF and FreeRTOS.

Q2. Is lwIP involved?
Yes, lwIP is enabled in the ESP-IDF project configuration, but the visible W5500 code path does not appear to rely on lwIP sockets or esp_eth integration.

Q3. Is the W5500 used in MACRAW mode?
No, the public startup sequence shows Socket 0 being opened in UDP mode, not MACRAW mode.

Q4. Is it using the W5500 hardwired TCP/IP engine?
Yes, that is the best interpretation of the public code. The project directly configures W5500 common/socket registers and prepares a UDP socket using the chip’s internal socket engine.

Q5. Does it use WIZnet’s official socket library?
It does not appear so in the public snapshot. The repository exposes a custom W5500 low-level driver rather than the typical WIZnet ioLibrary file structure.

Q6. Is SOME/IP fully implemented?
Not visibly, at least not end-to-end in the public snapshot. The repository clearly points toward SOME/IP, but the visible network bring-up is still centered on UDP socket initialization and Ethernet backbone work.