RP2040과 W5500으로 ZigBee Coordinator를 구축하는 방법은?

Summary

cod.m ZigBee Coordinator는 CC2652P2 ZigBee 무선 모듈을 Ethernet, Wi-Fi 또는 USB를 통해 호스트 시스템과 연결하기 위한 스마트홈 게이트웨이입니다. 개발 과정에서 RP2040 + WIZnet W5500 조합의 자체 설계 프로토타입이 실제로 제작되어 기본 기능까지 동작했습니다. 그러나 RP2040 Arduino Core의 네트워크 스택과 라이브러리 생태계 문제가 개발의 병목이 되었고, 최종 제품은 ESP32 + LAN8720 구조로 변경되었습니다. 따라서 이 프로젝트에서 W5500은 최종 제품의 Ethernet 컨트롤러가 아니라, 자체 ZigBee Coordinator를 개발하는 과정에서 검증된 Ethernet 프로토타입의 핵심 부품입니다.

What the Project Does

cod.m은 2022년 CC2652P2 ZigBee 모듈과 USR Ethernet 모듈을 결합한 초기 ZigBee Coordinator를 개발했습니다. 작은 PCB에 전압 변환 회로와 USB 커넥터를 배치하고 3D 프린팅 케이스를 사용하는 구조였으며, PoE는 외부 어댑터가 있어야 사용할 수 있었습니다.

2023년에는 PoE를 PCB에 직접 통합하고 자체 펌웨어를 개발하기 위해 완전한 재설계를 시작했습니다. 당시 원래 선호하던 ESP32는 구할 수 있었지만 Ethernet 연결에 필요한 LAN8720의 공급이 어려웠습니다. 

이에 개발팀은 다른 프로젝트에서 이미 경험이 있었던 RP2040과 W5500을 조합한 새로운 PCB를 설계했습니다. 자체 RP2040 펌웨어도 개발했으며, PoE를 제외한 기본 기능이 동작하는 프로토타입까지 완성했습니다.

이 시스템의 핵심 데이터 흐름은 다음과 같이 볼 수 있습니다.

ZigBee devices ↔ CC2652P2 ↔ Coordinator MCU ↔ Ethernet/USB/Wi-Fi ↔ Host system

여기서 CC2652P2가 ZigBee 무선 통신을 담당하고, Coordinator 측 MCU와 네트워크 인터페이스가 ZigBee 데이터를 IP 네트워크 또는 USB를 통해 외부 시스템으로 전달합니다.

그러나 2023년 여름부터 가을 사이 LAN8720의 공급 상황이 개선되면서 개발팀은 RP2040 + W5500 구조를 계속 유지할 것인지 다시 검토했습니다. RP2040 Arduino Core 환경에서는 필요한 라이브러리가 아직 포팅되지 않은 경우가 있었고, 표준 기능 일부를 다시 구현해야 했으며, 프로세스 동시성에도 문제가 있었다고 개발자는 설명합니다.

 결국 하드웨어와 펌웨어 방향을 ESP32 + LAN8720으로 변경했습니다.

최종 설계에는 PoE, USB-C, FT231X USB-Serial 인터페이스, 자동 리셋 회로 등이 추가되었으며 펌웨어는 기존 UZG Firmware를 기반으로 개발되었습니다.

Where WIZnet Fits

이 프로젝트에서 확인되는 WIZnet 제품은 W5500입니다.

W5500은 RP2040 기반 ZigBee Coordinator 프로토타입의 Ethernet 인터페이스로 선택되었습니다. 개발팀은 W5500을 이전 프로젝트에서 이미 사용해 본 경험이 있었으며, 이를 바탕으로 RP2040 + W5500 조합의 자체 PCB와 펌웨어를 개발했습니다. 원문은 이 프로토타입이 PoE 없이 기본 기능까지 실제로 동작했다고 명확히 설명합니다.

W5500은 MCU와 SPI로 연결되며 TCP/IP 처리를 하드웨어에서 담당하는 Ethernet 컨트롤러입니다. 8개의 하드웨어 소켓과 32 KB의 내부 송수신 버퍼를 제공하기 때문에 MCU가 Ethernet 프레임부터 전체 TCP/IP 프로토콜을 소프트웨어로 처리해야 하는 구조와는 설계 방식이 다릅니다.

이 점은 이번 사례에서 특히 중요합니다. RP2040 + W5500 하드웨어 자체가 실패한 것이 아닙니다. 원문에서 개발자가 지적한 문제는 RP2040 Arduino Core를 사용하는 전체 펌웨어 환경과 네트워크 스택 주변의 라이브러리 지원, 표준 기능, 동시성 문제였습니다. 실제로 RP2040/W5500 프로토타입은 기본 기능까지 동작했습니다.

반면 최종 제품에서 채택된 LAN8720은 W5500과 동일한 종류의 TCP/IP offload 컨트롤러가 아닙니다. LAN8720은 Ethernet PHY이므로 ESP32 측 Ethernet MAC 및 소프트웨어 네트워크 환경과 함께 사용됩니다.

따라서 이 프로젝트의 전환을 단순히 “W5500 대신 LAN8720이 더 적합했다”고 해석하는 것은 정확하지 않습니다. 실제 의사결정은 다음과 같은 플랫폼 단위의 비교였습니다.

RP2040 + W5500 + 당시 RP2040 Arduino 소프트웨어 환경

대

ESP32 + LAN8720 + 기존 ESP32용 펌웨어 및 라이브러리 생태계

개발팀은 두 번째 구조에서 기존 ZigBee Gateway 펌웨어를 활용할 수 있다는 점까지 고려해 최종적으로 ESP32 플랫폼을 선택했습니다.

Implementation Notes

원문에서는 RP2040/W5500 프로토타입의 사진과 개발 과정은 공개하지만, 해당 프로토타입의 W5500 펌웨어 소스 코드나 SPI 핀 정의, W5500 초기화 루틴은 제공하지 않습니다. 따라서 실제 프로젝트 코드처럼 보이는 초기화 예제를 제시할 근거는 없습니다.

확인 가능한 구현 수준은 다음과 같습니다.

RP2040 prototype

RP2040이 Coordinator의 MCU 역할을 하고 W5500이 Ethernet 연결을 제공하는 새로운 PCB가 제작되었습니다. 개발팀은 RP2040용 자체 펌웨어를 작성했고 PoE를 제외한 기본 기능이 동작하는 단계까지 구현했습니다.

ZigBee interface

초기 제품부터 CC2652P2가 ZigBee 무선 모듈로 사용되었습니다. 따라서 RP2040/W5500 버전에서도 네트워크 부분과 ZigBee 무선 부분을 분리한 Gateway 구조가 핵심입니다.

Final ESP32 implementation

RP2040 버전의 펌웨어를 계속 확장하는 대신 개발팀은 ESP32로 전환하고 기존 ZigBee Gateway 프로젝트를 검토했습니다. ZigStar-FW, ZiGate-Ethernet 및 UZG Firmware를 조사한 뒤 UZG Firmware를 fork했으며, USB passthrough 등의 변경 사항을 upstream 프로젝트에도 반영했다고 설명합니다.

이 사례에서 중요한 엔지니어링 포인트는 Ethernet 칩만 비교해서 플랫폼을 결정하지 않았다는 것입니다. MCU, Ethernet architecture, framework, 라이브러리 지원, 기존 오픈소스 펌웨어까지 하나의 시스템으로 평가한 결과 최종 아키텍처가 변경되었습니다.

Practical Tips / Pitfalls

• W5500의 SPI 배선을 먼저 검증해야 합니다. RP2040과 연결할 때 SCK, MOSI, MISO, CS를 기본으로 사용하며 실제 PCB에서는 RESET 및 INT 처리 방식도 함께 결정해야 합니다.
• PHY link와 TCP/IP 동작을 분리해서 디버깅하는 것이 좋습니다. Ethernet link가 올라오는 것과 ZigBee 데이터를 정상적으로 TCP/UDP로 전달하는 것은 서로 다른 검증 단계입니다.
• W5500의 소켓과 32 KB 내부 버퍼를 애플리케이션 요구사항에 맞게 배분해야 합니다. ZigBee Gateway가 실제로 몇 개의 동시 네트워크 연결을 필요로 하는지 먼저 정의하는 편이 좋습니다.
• MCU 지원 라이브러리를 Ethernet 칩 드라이버와 별도로 검토해야 합니다. 이 프로젝트에서도 하드웨어 프로토타입보다 RP2040 Arduino 환경의 라이브러리와 네트워크 관련 기능이 장기 개발의 제약으로 작용했습니다. 
• PoE는 Ethernet 통신과 별도의 전원 설계 문제입니다. 실제 cod.m 최종 제품에서도 PoE 구현을 위해 별도의 인터페이스 컨트롤러를 선정하고 USB 전원과의 전환 동작까지 설계해야 했습니다. 
• 프로토타입에서 양산 설계로 넘어가기 전에 소프트웨어 생태계를 검증해야 합니다. MCU 성능이나 Ethernet 컨트롤러 사양만으로 플랫폼을 결정하면 필요한 라이브러리, 멀티태스킹 또는 기존 펌웨어와의 호환성이 뒤늦게 병목이 될 수 있습니다.

유사 UCC

Canique Pico Gateway — 가장 유사

RP2040 + W5500으로 실제 Gateway를 구현한 프로젝트입니다. 무선 센서 데이터를 받아 복호화한 뒤 MQTT 서버로 전달하고, HTTP 서버와 설정 페이지, DHCP/static IP까지 제공합니다. 즉 cod.m의 ZigBee Coordinator처럼 무선 장치 ↔ RP2040 ↔ W5500 ↔ Ethernet 서버라는 구조가 매우 비슷합니다. 
Canique Pico Gateway

Raspberry Pi Pico + W5500 in Mongoose — 소프트웨어 문제 이해에 가장 유용

이 프로젝트는 RP2040 + W5500을 사용하지만 Arduino Core 대신 Pico SDK + Mongoose를 사용합니다. 특히 외부 lwIP나 FreeRTOS 없이 Mongoose의 TCP/IP stack과 W5500 driver를 이용해 MQTT와 Web dashboard를 구현합니다.

이 사례가 중요한 이유는 cod.m의 문제를 “RP2040이나 W5500 자체의 한계”와 “그 위에 선택한 소프트웨어 환경의 한계”를 분리해서 볼 수 있게 해주기 때문입니다.

Raspberry Pi Pico + W5500 in Mongoose

RP2040 + W5500 + Arduino IDE — cod.m의 Arduino Core 문제와 직접 비교 가능

이 UCC는 Raspberry Pi Pico/RP2040 + W5500을 Arduino IDE 환경에서 사용하면서 HTTP뿐 아니라 HTTPS까지 구현합니다. BearSSL wrapper를 추가해 Arduino Ethernet에서 TLS를 처리하는 방법까지 다룹니다.

즉 “RP2040 Arduino Core에서는 W5500을 못 쓴다”는 의미가 절대 아닙니다. W5500 Ethernet 자체는 사용할 수 있지만, 프로젝트에서 필요로 하는 상위 기능과 라이브러리까지 조합하기 시작하면 호환성 문제가 발생할 수 있다는 쪽으로 cod.m의 설명을 해석하는 것이 정확합니다.

RP2040 + W5500 HTTP/HTTPS with Arduino

Arduino Raspberry Pi Pico/RP2040-Ethernet — Arduino Core 자체 확인용

이것도 상당히 중요한 자료입니다. W5500-EVB-Pico에서 arduino-pico 지원과 Arduino Ethernet Library 사용을 직접 다룹니다. 따라서 RP2040 + W5500 + Arduino라는 조합 자체는 이미 지원됐다는 근거가 됩니다.

ZigBee Coordinator + W5500 Ethernet backhaul

 ESP32-C3가 Coordinator가 되고 W5500 Ethernet을 통해 Raspberry Pi MQTT broker와 연결하며, XBee3 ZigBee 장치들을 제어하는 구조입니다. MCU는 RP2040이 아니지만 ZigBee Coordinator + W5500 Ethernet backhaul이라는 애플리케이션 관점에서는 cod.m과 가장 직접적인 비교 대상입니다.

FAQ

Q: 왜 cod.m은 RP2040 프로토타입에 W5500을 사용했나요?
A: 개발팀은 다른 프로젝트를 통해 W5500 사용 경험을 이미 가지고 있었고, LAN8720 공급이 어려웠던 시기에 RP2040 + W5500 조합으로 자체 Ethernet ZigBee Coordinator를 개발했습니다. W5500은 TCP/IP 처리를 하드웨어에서 담당하는 구조이므로 RP2040과 SPI로 연결해 Ethernet 기능을 구성할 수 있으며, 실제 프로토타입도 기본 기능까지 동작했습니다.

Q: W5500은 RP2040에 어떻게 연결하나요?
A: W5500은 SPI 기반 Ethernet 컨트롤러이므로 RP2040과 SCK, MOSI, MISO, CS를 중심으로 연결합니다. RESET과 INT 사용 여부도 보드 설계에서 결정해야 합니다. 다만 cod.m이 사용한 정확한 GPIO 번호와 SPI 설정은 원문에 공개되어 있지 않으므로 해당 프로젝트의 실제 핀맵이라고 단정할 수 없습니다.

Q: W5500은 이 ZigBee Coordinator에서 정확히 어떤 역할을 했나요?
A: W5500은 RP2040 프로토타입에서 유선 Ethernet 네트워크 인터페이스를 담당했습니다. ZigBee 무선 통신 자체는 CC2652P2가 담당하므로 W5500의 역할은 ZigBee RF 칩을 대체하는 것이 아니라 Coordinator를 IP 네트워크에 연결하는 것입니다.

Q: 초보자도 RP2040 + W5500 ZigBee Coordinator를 만들 수 있나요?
A: 단순한 RP2040/W5500 Ethernet 연결보다 난도가 높습니다. SPI와 Ethernet뿐 아니라 CC2652P2와의 통신, ZigBee Gateway 동작, 네트워크 프로토콜, PCB 설계 등을 이해해야 합니다. 특히 원본 RP2040/W5500 펌웨어가 기사에 공개되어 있지 않기 때문에 이 프로젝트를 그대로 복제하는 형태의 초보자용 튜토리얼로 보기는 어렵습니다.

Q: W5500과 최종 제품의 LAN8720은 어떤 차이가 있나요?
A: W5500은 TCP/IP 기능과 소켓, 내부 송수신 버퍼를 포함하는 하드웨어 TCP/IP offload Ethernet 컨트롤러인 반면, LAN8720은 Ethernet PHY입니다. 따라서 두 칩만 직접 비교하기보다는 RP2040 + W5500과 ESP32 + LAN8720이라는 전체 시스템을 비교해야 합니다. cod.m이 ESP32로 변경한 핵심 이유 역시 W5500 자체의 동작 문제가 아니라 당시 RP2040 Arduino Core의 라이브러리, 네트워크 관련 기능 및 동시성 문제와 ESP32 측의 기존 소프트웨어 활용 가능성이었습니다.

Source

Original Project: Patrik Mayer, Der lange Weg zum cod.m ZigBee Coordinator, allgeek techblog, April 25, 2024.

Original Article: allgeek techblog – Der lange Weg zum cod.m ZigBee Coordinator

Related Firmware: The final ESP32 version is based on a fork of UZG Firmware; the author states that their changes are contributed back to the project.

License: The article does not state a reusable content license. The firmware projects discussed in the article are described by the author as GPL-licensed, but that should not be interpreted as the license of the article or the unpublished RP2040/W5500 prototype firmware.

Tags

#W5500 #RP2040 #ZigBee #CC2652P2 #Ethernet #ESP32 #LAN8720 #PoE #ZigBee2MQTT #SmartHome #IoT