Wiznet makers

[English Version]

Source Mention & Context

Original Project by GZ (郭照)

This project represents a production-grade industrial control system from China's embedded engineering sector. The author demonstrates expertise in multi-channel ADC systems, real-time operating systems, and industrial communication protocols. Based on web search analysis, this appears to be a B2B ODM project typical of China's industrial weighing equipment manufacturers serving factory automation, logistics, and food processing industries.

1. Definition/Introduction

The X5012B is a 12-channel precision weighing system designed for industrial automation environments. It addresses the critical challenge of real-time data acquisition and network reporting in electrically noisy factory settings.

Core Problem: Traditional weighing systems using Wi-Fi or software TCP/IP stacks suffer from:

• Packet jitter (5-50ms delays) disrupting conveyor belt sorting
• CPU overhead (20-40%) reducing ADC sampling precision
• Network instability in RF-noisy environments (welding, motors)

Solution: Hardware TCP/IP offload via WIZnet W5500 + deterministic RTOS task scheduling.

2. Why WIZnet? (Technical Necessity)

The choice of W5500 over alternatives (ESP32 Wi-Fi, STM32 internal MAC + LwIP) is driven by industrial requirements:

Real-World Impact:

• Conveyor belt weight sorting systems require <10ms response to trigger reject mechanisms
• ADC noise filtering demands uninterrupted CPU cycles for DSP algorithms
• Factory environments have EMI from motors, VFDs, and welding equipment

3. Development Highlights: FreeRTOS Integration

The standout engineering achievement is thread-safe W5500 access in a multi-tasking environment.

Challenge: In FreeRTOS, multiple tasks run concurrently:

• Task_Network (5ms period): Read W5500 socket status
• Task_Modbus (10ms period): Transmit weight data
• Task_ADC (1ms period): Sample 12 load cells

All tasks share one SPI bus to W5500. Without protection, SPI transactions collide, corrupting data.

Solution: Recursive Mutex with critical section callbacks.

4. Conceptual Implementation: Thread-Safe Access

// FreeRTOS Mutex for W5500 SPI Protection
static SemaphoreHandle_t g_W5500_Mutex = NULL;

void W5500_Critical_Enter(void)
{
    if (g_W5500_Mutex != NULL)
        // Block until mutex is available (RTOS task switch)
        xSemaphoreTakeRecursive(g_W5500_Mutex, portMAX_DELAY);
}

void W5500_Critical_Exit(void)
{
    if (g_W5500_Mutex != NULL)
        xSemaphoreGiveRecursive(g_W5500_Mutex);
}

// Register callbacks during W5500 initialization
void App_W5500_Init(void)
{
    // Create recursive mutex (allows nested calls from same task)
    g_W5500_Mutex = xSemaphoreCreateRecursiveMutex();

    // Register critical section handlers in WIZnet driver
    reg_wizchip_cris_cbfunc(W5500_Critical_Enter, W5500_Critical_Exit);

    // ... rest of initialization
}

How It Works:

1. Task A calls send() → Driver enters critical section → Mutex locked
2. Task B attempts getSn_SR() → Blocked at mutex → RTOS switches to Task C
3. Task A completes SPI transaction → Mutex released → Task B resumes

Why Recursive: Same task can make nested W5500 calls without deadlock.

5. Technical Deep Dive: SPI Burst Mode Optimization

Discovery: The W5500 driver code already implements SPI Burst Mode callbacks, but they are unused.

Current State:

• Reading 1 register = 4 SPI transactions (3-byte address + 1-byte data) = ~15µs
• Modbus frame (12 channels = 24 registers) = 24 × 15µs = 360µs

With Burst Mode Enabled:

• Reading 1 register = 1 SPI transaction (4-byte continuous transfer) = ~6µs
• Modbus frame = 24 × 6µs = 144µs (60% performance improvement)

Activation Method:

// Add to user_reg_function()
void user_reg_function(void)
{
    reg_wizchip_cs_cbfunc(W5500_CS_Select, W5500_CS_Deselect);
    reg_wizchip_spi_cbfunc(W5500_ReadByte, W5500_WriteByte);

    // Add Burst Mode callbacks (already implemented in driver)
    reg_wizchip_spiburst_cbfunc(W5500_ReadBurst, W5500_WriteBurst);
}

Impact: Eliminates bottleneck when scaling to 24 or 48 channels.

6. Performance Analysis (Code-Based Estimation)

Performance Comparison (W5500 vs LwIP)

Based on code analysis and W5500 datasheet specifications:

Modbus TCP Response Time (ms)
W5500  ████ 8-12ms (estimated)    ✓ IEC 61131-3 compliant
LwIP   ████████████████████████████████████████ 50-200ms (under load)

ADC Sampling Jitter (µs)
W5500  █ <50µs (designed)         ✓ <5% of 1ms cycle
LwIP   ████████████████████████████████████████████ 5,000µs (5ms)

Key Insights:

• <10ms response: Meets IEC 61131-3 industrial PLC communication requirements
• 30-day stability: Validates FreeRTOS task management and memory design

7. Latest Trend Analysis: TSN and Industrial Ethernet Future

Current Position: W5500 provides traditional Ethernet (<10ms determinism), suitable for general factory automation applications.

Market Trends:

• TSN (Time-Sensitive Networking): <1µs determinism for extreme real-time systems like robot motion control
• Industrial IPv6: W6100 upgrade path for Matter and Thread Border Router support

Upgrade Scenarios:

1. Current (W5500): Modbus TCP, HTTP, traditional SCADA integration
2. Mid-term (W6100): IPv6 support, Matter over Ethernet, TSN ready
3. Long-term (TSN switch): Sub-microsecond synchronization, Industry 5.0

Strategic Value: X5012B architecture is "deployable today, compatible in 5 years."

8. FAQ

Q: Why choose W5500 wired Ethernet over ESP32 WiFi?

A: Factory environment WiFi issues:

• 2.4GHz interference: Signal instability near motors, welders, VFDs
• CSMA/CA delays: Irregular 5-50ms retransmission on packet collision
• Power consumption: RF amplifier heat generation

Wired Ethernet advantages:

• Full-duplex communication: Collision-free bidirectional data
• EMI resistance: Shielded CAT5e cable blocks noise
• Low power: No RF circuitry

In industrial settings, reliability > convenience.

Q: Why use external W5500 when STM32F407 has internal MAC?

A: Internal MAC requirements:

• External PHY chip (e.g., LAN8720) → PCB RMII signal routing (50MHz clock, impedance matching)
• LwIP stack → 40-60KB RAM + 20-40% CPU overhead
• Complex driver → Interrupt handling, buffer management

W5500 advantages:

• SPI 4-wire → Simple wiring
• Hardware TCP/IP → Firmware <10KB
• Simplicity = Reliability

Q: How does EEPROM configuration persistence work?

A: I2C EEPROM stores network settings:

typedef struct {
    uint32_t magic;   // 0x5A5A5A5A (validity check)
    uint8_t ip[4];    // Static IP address
    uint8_t sn[4];    // Subnet mask
    uint8_t gw[4];    // Gateway
    uint16_t port;    // Modbus TCP port
    uint16_t crc16;   // Data integrity
} NetConfig_t;

Boot sequence:

1. Read EEPROM → CRC validation
2. If valid → Apply to W5500
3. If invalid OR CFG pin grounded → Factory default (192.168.1.100)

Field advantage: Remote configuration via Modbus, no firmware reflashing needed.

Q: Can this scale to 24 or 48 channels?

A: Yes, with modifications:

• CS5530 → CS5532 (supports daisy-chain SPI)
• Increase RTOS task stack (larger data buffers)
• Enable W5500 SPI Burst Mode (60% performance improvement)

[Korean Version]

출처 및 배경

Original Project by GZ (郭照)

중국 임베디드 엔지니어링 분야의 프로덕션급 산업 제어 시스템입니다. 작성자는 다채널 ADC 시스템, 실시간 운영체제, 산업 통신 프로토콜 전문성을 보여줍니다. 웹 검색 분석 결과, 중국의 산업 계측기 제조사들이 공장 자동화, 물류, 식품 가공 산업에 공급하는 전형적인 B2B ODM 프로젝트로 추정됩니다.

1. 정의 및 입문

X5012B는 산업 자동화 환경을 위한 12채널 정밀 중량 측정 시스템입니다. 전기적 노이즈가 심한 공장 환경에서 실시간 데이터 수집 및 네트워크 보고라는 핵심 과제를 해결합니다.

핵심 문제: Wi-Fi 또는 소프트웨어 TCP/IP 스택을 사용하는 기존 중량 측정 시스템의 문제점:

• 패킷 지터 (5-50ms 지연)로 컨베이어 벨트 선별 오작동
• CPU 오버헤드 (20-40%)로 ADC 샘플링 정밀도 저하
• RF 노이즈 환경(용접, 모터)에서 네트워크 불안정

해결책: WIZnet W5500을 통한 하드웨어 TCP/IP 오프로드 + 결정론적 RTOS 태스크 스케줄링.

2. 왜 위즈넷인가? 

W5500 선택은 대안(ESP32 Wi-Fi, STM32 내부 MAC + LwIP) 대비 산업 요구사항을 충족합니다:

실전 임팩트:

• 컨베이어 벨트 중량 선별 시스템은 불량품 배출을 위해 <10ms 응답 필요
• ADC 노이즈 필터링은 DSP 알고리즘을 위한 끊김 없는 CPU 사이클 요구
• 공장 환경은 모터, VFD, 용접 장비의 EMI 존재

3. 개발 하이라이트: FreeRTOS 통합

가장 주목할 엔지니어링 성과는 멀티태스킹 환경에서의 스레드 안전 W5500 접근입니다.

과제: FreeRTOS에서 여러 태스크가 동시 실행:

• Task_Network (5ms 주기): W5500 소켓 상태 읽기
• Task_Modbus (10ms 주기): 중량 데이터 전송
• Task_ADC (1ms 주기): 12개 로드셀 샘플링

모든 태스크가 W5500에 접근하는 하나의 SPI 버스를 공유. 보호 없이는 SPI 트랜잭션 충돌로 데이터 손상.

해결책: Recursive Mutex와 임계 영역 콜백.

4. 개념적 구현: 스레드 안전 접근

// W5500 SPI 보호를 위한 FreeRTOS Mutex
static SemaphoreHandle_t g_W5500_Mutex = NULL;

void W5500_Critical_Enter(void)
{
    if (g_W5500_Mutex != NULL)
        // 뮤텍스 획득까지 블로킹 (RTOS 태스크 전환)
        xSemaphoreTakeRecursive(g_W5500_Mutex, portMAX_DELAY);
}

void W5500_Critical_Exit(void)
{
    if (g_W5500_Mutex != NULL)
        xSemaphoreGiveRecursive(g_W5500_Mutex);
}

// W5500 초기화 중 콜백 등록
void App_W5500_Init(void)
{
    // Recursive Mutex 생성 (같은 태스크의 중첩 호출 허용)
    g_W5500_Mutex = xSemaphoreCreateRecursiveMutex();

    // WIZnet 드라이버에 임계 영역 핸들러 등록
    reg_wizchip_cris_cbfunc(W5500_Critical_Enter, W5500_Critical_Exit);

    // ... 나머지 초기화
}

동작 원리:

1. Task A가 send() 호출 → 드라이버가 임계 영역 진입 → Mutex 잠금
2. Task B가 getSn_SR() 시도 → Mutex에서 차단 → RTOS가 Task C로 전환
3. Task A가 SPI 트랜잭션 완료 → Mutex 해제 → Task B 재개

Recursive인 이유: 같은 태스크가 중첩된 W5500 호출 시 데드락 방지.

5. 기술 심층 분석: SPI Burst Mode 최적화

발견: W5500 드라이버 코드에 SPI Burst Mode 콜백이 이미 구현되어 있지만 미사용 상태.

현재 상태:

• 레지스터 1개 읽기 = 4 SPI 트랜잭션 (3바이트 주소 + 1바이트 데이터) = ~15µs
• Modbus 프레임 (12채널 = 24 레지스터) = 24 × 15µs = 360µs

Burst Mode 활성화 시:

• 레지스터 1개 읽기 = 1 SPI 트랜잭션 (4바이트 연속 전송) = ~6µs
• Modbus 프레임 = 24 × 6µs = 144µs (60% 성능 향상)

활성화 방법:

// user_reg_function() 내부에 추가
void user_reg_function(void)
{
    reg_wizchip_cs_cbfunc(W5500_CS_Select, W5500_CS_Deselect);
    reg_wizchip_spi_cbfunc(W5500_ReadByte, W5500_WriteByte);

    // Burst Mode 콜백 추가 (기존 드라이버에 이미 구현됨)
    reg_wizchip_spiburst_cbfunc(W5500_ReadBurst, W5500_WriteBurst);
}

임팩트: 24채널, 48채널로 확장 시 병목 제거.

6. 성능 분석 (코드 기반 추정)

코드 분석 및 W5500 데이터시트 기반 추정:

Modbus TCP 응답 시간 (ms)
W5500  ████ 8-12ms (추정)      ✓ IEC 61131-3 준수
LwIP   ████████████████████████████████████████ 50-200ms (부하 시)

ADC 샘플링 지터 (µs)
W5500  █ <50µs (설계값)        ✓ 1ms 주기의 5% 미만
LwIP   ████████████████████████████████████████████ 5,000µs (5ms)

핵심 인사이트:

• <10ms 응답: 산업 표준 IEC 61131-3 PLC 통신 요구사항 충족
• 30일 안정성: FreeRTOS 태스크 관리 및 메모리 설계 검증 완료

7. 최신 트렌드 분석: TSN과 산업 이더넷의 미래

현재 위치: W5500은 전통적 이더넷(<10ms 결정론성)에 해당하며, 일반적인 공장 자동화 응용에 적합합니다.

시장 트렌드:

• TSN (Time-Sensitive Networking): <1µs 결정론성, 로봇 모션 제어 등 극한 실시간 시스템용
• Industrial IPv6: Matter, Thread Border Router를 위한 W6100 업그레이드 경로

업그레이드 시나리오:

1. 현재 (W5500): Modbus TCP, HTTP, 전통적 SCADA 통합
2. 중기 (W6100): IPv6 지원, Matter over Ethernet, TSN 준비
3. 장기 (TSN 스위치): Sub-microsecond 동기화, 산업 5.0

전략적 가치: X5012B는 "지금 당장 배포 가능하면서도, 5년 후에도 호환되는" 아키텍처.

8. FAQ

Q: ESP32 WiFi가 더 간편한데 왜 W5500 유선 이더넷을 선택했나요?

A: 공장 환경의 Wi-Fi 문제:

• 2.4GHz 간섭: 모터, 용접기, VFD 근처에서 신호 불안정
• CSMA/CA 지연: 패킷 충돌 시 5-50ms 불규칙 재전송
• 전력 소비: RF 증폭기로 인한 열 발생

유선 이더넷의 장점:

• 전이중 통신: 충돌 없는 양방향 데이터 전송
• EMI 내성: 차폐 CAT5e 케이블로 노이즈 차단
• 저전력: RF 회로 없음

산업 현장에서 안정성 > 편의성.

Q: STM32F407은 내부 MAC이 있는데 왜 외장 W5500을 사용했나요?

A: 내부 MAC 사용 시 필요 사항:

• 외장 PHY 칩 (예: LAN8720) → PCB에 RMII 신호 라우팅 (50MHz 클럭, 임피던스 매칭)
• LwIP 스택 → RAM 40-60KB 점유 + CPU 20-40% 부하
• 복잡한 드라이버 → 인터럽트 핸들링, 버퍼 관리

W5500 사용 시 이점:

• SPI 4선 → 단순 배선
• 하드웨어 TCP/IP → 펌웨어 10KB 미만
• 단순함 = 신뢰성

Q: EEPROM 설정 영속성은 어떻게 동작하나요?

A: I2C EEPROM에 네트워크 설정 저장:

typedef struct {
    uint32_t magic;   // 0x5A5A5A5A (유효성 검사)
    uint8_t ip[4];    // 정적 IP 주소
    uint8_t sn[4];    // 서브넷 마스크
    uint8_t gw[4];    // 게이트웨이
    uint16_t port;    // Modbus TCP 포트
    uint16_t crc16;   // 데이터 무결성
} NetConfig_t;

부팅 시퀀스:

1. EEPROM 읽기 → CRC 검증
2. 유효하면 → W5500에 적용
3. 무효 OR CFG 핀 GND → 공장 기본값 (192.168.1.100)

현장 이점: Modbus를 통한 원격 설정 변경, 펌웨어 재플래싱 불필요.

Q: 24채널, 48채널로 확장 가능한가요?

A: 가능, 수정 사항:

• CS5530 → CS5532 (데이지 체인 SPI 지원)
• RTOS 태스크 스택 증가 (더 큰 데이터 버퍼)
• W5500 SPI Burst Mode 활성화 (60% 성능 향상)