AASun
AASun
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
→ 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
----------- --------
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
| Socket | Protocol | Purpose |
|---|---|---|
| 0 | TCP | HTTP server |
| 1 | TCP | Telnet CLI |
| 2 | UDP | DNS client |
| 3 | UDP | SNTP 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:
→ 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?

