Wiznet makers

[Project Story] Realtek BW16 + W5500 유선 이더넷 도전기

— 컴파일 에러에서 Proof-of-Concept 성공까지

이 글은 Realtek BW16 (RTL8720DN) 보드에
WIZnet W5500을 붙여 유선 이더넷을 구현하기까지의
실제 시도 과정을 시간 순서대로 정리한 히스토리입니다.

주인공은 Arduino 포럼의 유저 high_voltage / Aurangzeb Haque 님으로,
여러 번의 실패와 우회를 거쳐 결국 Arduino 툴체인 + BW16 + W5500 조합의 PoC를 완성했습니다. 

1. 출발점 – BW16 첫 사용 & 전원 이슈 (2023-06)

프로젝트의 아주 초창기는 BW16 자체를 익히는 단계였습니다.

BW16C 보드를 처음 사용하면서,

3.3V / 5V 핀으로 전원을 넣으면 동작하지 않고

USB를 연결해야만 Blink 예제가 동작하는 문제를 경험

커뮤니티 도움을 받아 전원 연결 및 보드 특성을 이해하고,

결국 안정적으로 Vin + GND로만 구동 성공

이 시기에는 아직 W5500이 아니라,
“BW16이 도대체 어떻게 돌아가는 칩인가?”를 탐색하는 단계였습니다.

2. 2개의 시리얼 포트 & SoftwareSerial 실험 (2024-03)

다음 단계는 BW16의 시리얼 포트 활용이었습니다.

목표
→ BW16에서 두 개의 UART를 동시에 사용
→ 하나는 업로드용(USB-UART), 다른 하나는 별도 통신용(SoftwareSerial)

SoftwareSerial 예제를 BW16에 맞게 수정:

SoftwareSerial mySerial(PB2, PB1); // RX, TX

초기에는 출력이 나오지 않았지만,

시퀀스를 조정하고,

mySerial.begin()과 Serial.begin()의 위치를 다듬으면서

최종적으로 두 개의 시리얼 포트 동시 운용 성공

이 경험은 나중에 **Ethernet 브리지 구현(시리얼 ↔ 이더넷)**을 위한 사전 준비가 됩니다.

3. SPI 루프백 테스트 – BW16의 SPI 신뢰성 확보 (2024-04 초)

이제 본격적으로 W5500을 다루기 위한 SPI 신뢰성 검증 단계로 넘어갑니다.

3.1 8-bit 전송(transfer) 루프백

MOSI → MISO를 물리적으로 루프백시켜

아래와 같은 코드로 테스트:

→ 정상 동작 확인
→ BW16의 SPI 하드웨어, 기본 라이브러리, 핀 구성은 이상 없다는 결론.

3.2 16-bit 전송(transfer16) 시도 & 실패

같은 컨셉으로 SPI.transfer16() 기반 루프백 코드를 작성했지만,

오실로스코프에서 CLK가 8비트까지만 나오고 멈추는 현상 관찰

수신 데이터는 계속 0만 나옴

원인 후보:

SPI.transfer16() 사용 방식

SPISettings / 모드

RTL8720( BW16 )용 Arduino SDK에서의 구현 상태

이 당시에는 transfer()는 정상, transfer16()은 의심 상태였고,
이후 여러 번의 코드 수정과 테스트를 거치게 됩니다.

4. W5500 실제 연결 – VERSIONR 레지스터 읽기 도전 (2024-04 중)

SPI가 루프백에서 잘 되자, 드디어 W5500을 실제로 붙여보기 시작합니다.

4.1 VERSIONR 레지스터 읽기 시도 (실패)

목표
→ W5500의 VERSIONR 레지스터를 읽어 datasheet의 값(예: 0x04)을 확인

CS/CLK/MISO/MOSI 핀을 직접 선언하고,

SPI.transfer16() + SPI.transfer()를 조합해

주소 → 컨트롤 → 데이터 순으로 보내는 코드 작성

하지만 결과는 계속 0과 같은 잘못된 값

이 과정에서:

CS/SS 핀이 부동(Floating) 상태라는 점 발견

외부 풀업이 필요하다는 Wiznet 포럼의 회로 참고
→ 이후 “Digital pin internal pullup query” 스레드에서

BW16의 SPI 핀에 내부 풀업을 걸 수 있는지 질문

외부 6.8k 풀업을 추가한 뒤,

VERSIONR가 **‘1’**로 읽히는 단계까지 개선

아직 datasheet 값(4)와 다르지만,
하드웨어 연결/풀업/CS 제어가 결과에 영향을 주고 있다는 점은 확인했습니다.

5. transfer16() 재도전 & 성공, 그리고 코드 구조 개선 (2024-04 중·후)

여러 차례 시도 후,
SPI.transfer16()도 올바르게 동작한다는 것을 결국 확인하게 됩니다.

MOSI와 MISO를 물리적으로 단락한 상태에서

transfer16() 루프백 코드를 돌려보면:

보낸 16비트 값과 받는 값이 일치

HEX 출력도 정상

즉, 문제는:

transfer16() 자체의 버그라기보다는

W5500과의 프로토콜 구현,

CS 제어 타이밍,

주소/컨트롤 바이트 구성 쪽에 더 가까운 것으로 정리됩니다.

이때 참고한 코드:

Adafruit/Ladyada의 Ethernet2 라이브러리의 write() 구현

SPI.transfer16(address) 대신

상위/하위 바이트를 transfer()로 나눠 보내는 방식과 비교

최종적으로:

W5500 레지스터 접근 함수 구조를

write_reg() / read_reg() 로 나누어,

SPI 트랜잭션과 CS 제어를 명시적으로 하는 방향으로 설계

6. W5500 + BW16 SPI 하드웨어 이슈들 (CS, 풀업, DMA 등)

히스토리 전반에서 반복적으로 등장하는 포인트들:

CS/SS 핀 풀업 문제

W5500 모듈의 CS/SS가 떠 있는 경우 → 오작동 및 쓰레기 데이터

BW16 쪽 내부 풀업 사용 여부 + 외부 6.8k~10k 저항 추가가 도움이 됨

핀맵/모드 설정

BW16이 가진 SPI 확장 기능 (extended CS handling)

SPI.begin(pin) / SPI.beginTransaction(pin, settings) 사용 여부

SPI_HAS_EXTENDED_CS_PIN_HANDLING 매크로의 의미 확인

전송 모드

SPI.transfer16(data, SPI_LAST) vs SPI.transfer16(data, SPI_CONTINUE)

라이브러리에서 실제 사용하는 패턴과 맞추는 작업

DMA/캐시 문제(다른 MCU 사례 포함)

STM32H7 + W5500 + DMA 환경에서의 어려움 사례도 참고

대역폭 요구가 크면 단순 폴링보다 DMA 설계가 중요해짐

이 모든 경험이 나중에 라이브러리 포팅 시 고려해야 할 체크리스트가 됩니다.

7. Ethernet 라이브러리 컴파일 에러 & UDP.h 이슈 (2024-12)

W5500 하드웨어만의 문제가 아니라,
Arduino 라이브러리 레벨의 문제도 동시에 존재했습니다.

7.1 Ethernet.h 사용 시 컴파일 실패

목표:

기존 Ethernet.h / EthernetUdp.h 예제를
BW16 + W5500 조합에 그대로 적용해 보기

하지만 BW16용 Arduino SDK(Ameba-D) 환경에서는:

UDP.h 관련 오류로 컴파일 실패

코어 디렉토리에 UDP.h를 직접 추가해보기도 했지만 해결 안 됨

GitHub 이슈까지 연결:

Ameba-AIoT/ameba-arduino-d 저장소에
“UDP.h is missing in core” 이슈가 열렸다가 해결된 이력 확인

또한 이 시점에 개발자는:

“ATmega328은 Ethernet 라이브러리로 W5500 쉴드에 잘 붙는데,
왜 BW16(8720DN)은 안 되는가?”라는 의문을 제기

BW16의 장점이었던 5GHz Wi-Fi가
ESP32-C5 등장으로 희석되고 있음을 언급하며,
Realtek이 Ethernet 지원에 더 신경 써주길 공개적으로 요청하기도 합니다.

8. BW16 Wi-Fi ↔ Ethernet 브리지 아이디어 & CH9121로의 우회 (2025-02)

한 번은 W5500을 잠시 내려놓고,
“BW16 5GHz Wi-Fi ↔ 유선 Ethernet 브리지” 프로젝트를 시도합니다.

8.1 1차 시도: BW16 + W5500 브리지

아이디어:

BW16의 5GHz Wi-Fi를 활용해 고성능 무선 구간을 만들고,

W5500으로 유선 이더넷에 브리징

하지만 앞서 언급한 Ethernet.h 호환성 문제로 난항

8.2 2차 시도: CH9121 시리얼–이더넷 모듈로 방향 전환

전략 변경:

W5500 대신 CH9121(serial ↔ Ethernet 모듈) 사용

이유:

자체 TCP/UDP 스택 내장

BW16에서는 단순히 UART만 사용하면 되므로 라이브러리 의존성이 낮음

계획:

BW16에서 AP 모드 + 간단한 캡티브 포털 페이지 제공

시리얼로 CH9121과 데이터 교환

이 브리지 프로젝트 경험은,

나중에 다시 W5500으로 돌아왔을 때
“하드웨어/펌웨어 분리 설계” 관점에서 도움이 됩니다.

9. 최종 장면 – EthernetRTL_BW16 프로젝트 공개 (2025-10~11)

여러 시행착오 끝에,
개발자는 다시 W5500 + BW16 조합으로 복귀합니다.

9.1 프로젝트 정리: EthernetRTL_BW16

프로젝트명: EthernetRTL_BW16

목표:

Ethernet3 라이브러리를 BW16용으로 어댑트

최소한 컴파일 타임에서 W5500 연동을 검증하고,

이후 실제 하드웨어 통신까지 확장

9.2 Proof-of-Concept 발표 (2025-11-02)

Arduino 포럼에 “[Project Release] Wired Ethernet for Realtek BW16 (RTL8720DN) using W5500 + Arduino — Proof-of-Concept Success!”라는 제목으로 공개:

하이라이트

✅ Ameba-D Arduino Core 3.1.9 기반

✅ WIZnet W5500 SPI Ethernet 컨트롤러 사용

✅ W5500_TestCompile.ino 기준 깨끗한 컴파일 성공

✅ 회로도 PDF + 결선 이미지 제공

✅ 구조화된 README.md와 Activity_Log.md로 진행 상황 공개

주의 사항

BW16 보드는 벤더마다 SPI 핀맵이 다를 수 있음

펌웨어 variant 매핑 수정 필요할 수 있음 (variant.cpp 편집)

9.3 Activity_Log로 본 최근 진행 상황 (2025-10~11)

Activity_Log.md 일부:

2025-10-26

Realtek BW16 (Ameba-D) SDK v3.1.9에서
Ethernet3_BW16 스텁 컴파일 성공

Ethernet 라이브러리가 BW16 타깃을 인식하는지 PoC 확보

2025-11-02

BW16, W5500 모듈, USB-Serial 어댑터를 동일 보드에 장착

펌웨어 업로드용 USB-Serial 연결 검증 완료

다음 단계 계획:

Blink.ino 업로드로 펌웨어 통신 확인

SPI 라인 W5500에 연결 후 이더넷 동작 검증

브레드보드 사진을 리포지토리에 업로드 (docs/media/Breadboard.png)

아직 “완성된 제품” 단계는 아니지만,
BW16 + W5500 + Arduino 조합이 실제로 굴러갈 수 있는 기반은
명확하게 마련된 셈입니다.

10. 이 히스토리가 주는 인사이트

이 한 사람의 긴 히스토리를 통해,
W5500 + 새로운 MCU/플랫폼을 붙일 때 유용한 교훈을 정리하면:

전원 & 하드웨어 기본기

보드 전원 경로, Vin/3.3V/USB 관계를 정확히 이해해야 한다.

CS/SS, MOSI, MISO, CLK에 부동 상태가 없는지 꼭 확인.

필요시 외부 풀업 저항을 추가.

SPI는 반드시 루프백으로 먼저 검증

transfer() → transfer16() 순서로,

“MCU + 라이브러리 + 핀 설정” 조합이 안정적인지 확인 후

그다음에 W5500을 붙이는 것이 훨씬 효율적.

라이브러리/코어 호환성은 별도 문제

하드웨어가 좋아도, 코어에서 UDP.h, Ethernet.h가 안 맞으면 막힌다.

필요하다면:

Ethernet 라이브러리를 포크해서 포팅하거나,

더 단순한 드라이버(예: W5500 전용 저수준 드라이버)를 먼저 붙이는 전략도 고려.

우회로도 전략적으로 활용

중간에 CH9121 같은 시리얼–Ethernet 모듈로 돌아가는 것도
“아이디어를 검증하는 단계”에서는 충분히 합리적인 선택이다.

기록을 남기면 커뮤니티 자산이 된다

high_voltage님처럼:

포럼 글, Activity_Log, README, GitHub 리포지토리를 통해

시행착오를 기록하면

이후 같은 문제를 겪을 다른 메이커들에게 큰 도움이 된다.

마무리

이 히스토리는 아직 진행 중인 프로젝트의 중간 기록이지만,
WIZnet W5500을 새로운 플랫폼에 포팅하고 싶은 메이커/엔지니어에게
아주 현실적인 로드맵과 함정을 함께 보여줍니다.

maker.wiznet.io에서는 앞으로도 이런 “실전 히스토리 기반” 사례들을 계속 소개하면서,
W5500 및 WIZnet 제품을 활용한 다양한 시도들을 아카이브해 나가겠습니다.

📎 프로젝트 리포지토리
EthernetRTL_BW16: https://github.com/azhaque59/EthernetRTL_BW16