Wiznet makers

TheoIm

Published March 27, 2026 ©

78 UCC

27 WCC

7 VAR

0 Contests

0 Followers

0 Following

Original Link

AASun

AASun

COMPONENTS Hardware components

WIZnet - W5500

x 1


PROJECT DESCRIPTION

What the Project Does

AASun is an edge energy controller designed to maximize solar self-consumption.

Instead of exporting excess solar energy to the grid, it:

Measures real-time power (voltage + current)

Detects surplus energy

Dynamically redirects that energy to local loads

Exposes system status via a web dashboard

Core Data Flow

 
Solar Production → Power Measurement (ADC + DMA)
                → Energy Calculation Engine
                → Surplus Detection
                → PWM Control (SSR loads)
                → W5500 → Web UI / Remote Access
 

Key Inputs and Outputs

Inputs:

CT sensors (current)

AC voltage reference

Smart meter (Linky via UART)

Temperature sensors (DS18B20)

Outputs:

SSR-controlled loads (water heater, heating)

Relay control

Network services (HTTP, Telnet)


Where WIZnet Fits

The system uses a W5500 Ethernet controller over SPI2 as its network backbone.

Role of W5500 in This Architecture

Provides hardware TCP/IP offload

Handles:

HTTP server connections

Telnet CLI sessions

DNS resolution

SNTP time synchronization

Interfaces with STM32 via SPI, minimizing MCU overhead

Why W5500 is Critical Here

This system runs on:

Cortex-M0+ @ 64 MHz

No large RAM

Real-time control loop (50 Hz synchronized)

Without W5500:

A software TCP/IP stack (e.g., LwIP) would:

consume CPU cycles

introduce timing jitter

risk breaking real-time control

With W5500:

The MCU focuses entirely on energy computation and control, while networking runs independently in hardware.


Implementation Notes

1. SPI-Based W5500 Integration

Hardware Interface

 
STM32G071        W5500
-----------      --------
PB13 (SCK)      SCLK
PB15 (MOSI)     MOSI
PB14 (MISO)     MISO
PC6  (CS)       /SCS
PC7  (RST)      /RESET
 

Why this matters:

Uses SPI2 with DMA support

Allows non-blocking communication with W5500

Keeps CPU available for control loop


2. Multi-Service Socket Allocation

SocketProtocolPurpose
0TCPHTTP server
1TCPTelnet CLI
2UDPDNS client
3UDPSNTP client

Why this matters:

W5500 supports up to 8 hardware sockets

Each service runs independently in hardware

No software socket scheduler required


3. HTTP Server with External Flash

Web assets stored in W25Q64 SPI flash

File system: MFS (custom lightweight FS)

Flow:

 
HTTP Request → W5500 socket
             → STM32 reads file from SPI flash
             → Response sent via W5500
 

Why this matters:

MCU internal flash is preserved

Large web UI (HTML/CSS/JS) is supported

Enables rich dashboard + history graphs


4. Real-Time Energy + Network Coexistence

The system runs:

50 kHz ADC sampling (DMA)

50 Hz synchronized power calculations

PID control loop (10 ms cycle)

At the same time:

HTTP requests

Telnet sessions

DNS + SNTP

Why this works:

W5500 isolates all network processing from the real-time control loop.


5. Time Synchronization (SNTP)

Uses UDP socket for SNTP

Syncs system clock with NTP servers

Why this matters:

Enables accurate:

energy logs (15-min intervals)

31-day history tracking

rule-based automation (time conditions)


Practical Tips / Pitfalls

Use DMA for SPI to avoid blocking during network bursts

Allocate sockets carefully—HTTP and Telnet must not conflict

Ensure proper W5500 reset timing (important for stability)

Keep ISR and control loop independent from network handling

External flash access must be fast enough for HTTP responses

Watch EMI/noise when mixing analog CT sensing and Ethernet

 


FAQ

Why is W5500 preferred over Wi-Fi in this system?

Because this system is real-time control critical. Wi-Fi introduces unpredictable latency, interference, and stack overhead. W5500 provides deterministic Ethernet communication and eliminates RF interference near sensitive analog measurements.


What exactly does W5500 handle internally?

W5500 implements:

TCP/UDP protocol stack

Packet buffering

Retransmissions and ACK handling

Checksum generation
This removes all networking burden from the MCU.


How does W5500 improve control stability?

By offloading networking, the MCU avoids:

interrupt spikes from network stacks

blocking socket operations

timing jitter
This ensures the 50 Hz synchronized control loop remains stable.


Why use multiple sockets instead of one?

Each service (HTTP, Telnet, DNS, SNTP) runs independently:

prevents blocking between services

allows concurrent connections

leverages W5500 hardware parallelism


How is real-time power accuracy maintained?

50 kHz ADC sampling

DMA-based buffering (no CPU overhead)

synchronized to AC cycle (20 ms)

oversampling improves resolution (~14-bit effective)


What is the role of the external flash (W25Q64)?

Stores web UI files

Logs historical energy data (31 days)

Reduces MCU flash usage

Enables scalable UI features


Source

AASun Solar Energy Diverter Project

STM32 + WIZnet W5500 architecture


Tags

W5500, WIZnet, STM32, Solar Energy, Energy Diverter, Embedded Ethernet, Real-Time Control, Smart Grid, PID Control, Edge IoT


Would you like a Korean translation?

Documents
Comments Write