--- title: "How to Build a Dual-Mode Industrial IoT Node with WIZnet W5500 on nRF52840?" url: "https://maker.wiznet.io/gavinchang/projects/how-to-build-a-dual-mode-industrial-iot-node-with-wiznet-w5500-on-nrf52840/" markdown_url: "https://maker.wiznet.io/gavinchang/projects/how-to-build-a-dual-mode-industrial-iot-node-with-wiznet-w5500-on-nrf52840/md" type: "UCC: User Created Content" author: "weixin_34195364" author_url: "https://blog.csdn.net/weixin_34195364/article/details/93458705?ops_request_misc=elastic_search_misc&request_id=8b975688a4e16db3a94de29c5045a482&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~ElasticSearch~search_v2-14-93458705-null-null.142^v102^pc_search_result_base4&utm_term=w5500%20ble&spm=1018.2226.3001.4187" editor: "WIZnet" editor_url: "https://maker.wiznet.io/" original_author: "weixin_34195364" original_url: "https://blog.csdn.net/weixin_34195364/article/details/93458705?ops_request_misc=elastic_search_misc&request_id=8b975688a4e16db3a94de29c5045a482&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~ElasticSearch~search_v2-14-93458705-null-null.142^v102^pc_search_result_base4&utm_term=w5500%20ble&spm=1018.2226.3001.4187" published: "2026-11-06" language: "en" likes: 0 views: 7 comments: 0 source: "WIZnet Makers (https://maker.wiznet.io/)" --- # How to Build a Dual-Mode Industrial IoT Node with WIZnet W5500 on nRF52840? > The nRF52840 and WIZnet W5500 can be combined to create an industrial IoT node with Bluetooth Low Energy (BLE) for local configuration and wired Ethernet for re Original author: weixin_34195364 (source: https://blog.csdn.net/weixin_34195364/article/details/93458705?ops_request_misc=elastic_search_misc&request_id=8b975688a4e16db3a94de29c5045a482&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~ElasticSearch~search_v2-14-93458705-null-null.142^v102^pc_search_result_base4&utm_term=w5500%20ble&spm=1018.2226.3001.4187) ## Article ## How to Build a Dual-Mode Industrial IoT Node with WIZnet W5500 on nRF52840? ### 1. Summary The nRF52840 and WIZnet W5500 can be combined to create an industrial IoT node with Bluetooth Low Energy (BLE) for local configuration and wired Ethernet for remote telemetry and control. The nRF52840 manages BLE communication, sensors, and application logic, while the W5500 provides hardware TCP/IP processing through an SPI interface. This architecture separates short-range maintenance access from the primary wired network connection, reducing the microcontroller resources needed for Ethernet communication. The design is described in a CSDN technical article published on August 17, 2026. It presents an architecture and illustrative firmware examples rather than a publicly verifiable, completed hardware implementation. W5500 usage is explicitly described, but operational results and a buildable source repository are not provided. blog.csdn.net ### 2. What the Project Does Industrial IoT nodes often require two different types of network access. A maintenance technician needs a short-range connection for equipment configuration, while a supervisory application needs a persistent connection to receive sensor measurements and issue commands. The proposed nRF52840–W5500 system addresses these requirements by assigning separate responsibilities to BLE and Ethernet. Proposed system architecture BLE Maintenance App Configuration and diagnostics Industrial Server Telemetry and commands BLE / GATT Wired Ethernet / TCP or UDP nRF52840 BLE stack, data processing, application W5500 Hardware TCP/IP, Ethernet MAC/PHY nRF52840 ↔ W5500: SPI + interrupt/reset GPIO Sensors and Actuators Measurements, digital inputs, control outputs Logical architecture derived from the source article; not a verified physical wiring diagram. #### Communication flow Sensor-to-server telemetry: Sensors supply measurements through interfaces such as I²C, SPI, or ADC. The nRF52840 processes and packages the values, writes data to the W5500 through SPI, and uses a TCP or UDP socket to transfer the payload over Ethernet. Server-to-device control: Incoming Ethernet messages arrive at W5500 receive buffers. The controller can signal the nRF52840 using its interrupt output. Firmware retrieves the payload, validates the command, and updates the relevant actuator or application state. Local BLE maintenance: A smartphone connects to the nRF52840 using GATT services. The article proposes BLE characteristics for network status, server configuration, sensor notifications, and maintenance commands. One architectural distinction matters: this is an application-level dual-interface node, not automatically a transparent BLE-to-Ethernet bridge. Moving information between BLE and Ethernet requires explicit application logic, message queues, synchronization, and access controls. blog.csdn.net ### 3. Where WIZnet Fits The selected Ethernet controller is the WIZnet W5500. It connects to the nRF52840 over SPI and handles core IPv4 networking functions in hardware. ## 8 Hardware sockets ## 32 KB Internal TX/RX memory ## 80 MHz Maximum SPI clock ## 10/100 Ethernet PHY, Mbps W5500 hardware specifications from WIZnet documentation. WIZnet Document System #### Why hardware TCP/IP matters The nRF52840 has a 64 MHz Cortex-M4F processor with 256 KB RAM and 1 MB flash. It already needs resources for BLE events, sensor processing, and application tasks. Adding a full software TCP/IP stack would introduce more code, memory allocations, and protocol-processing work. The W5500 handles operations such as TCP connection management, retransmissions, checksums, and packet buffering in hardware. The nRF52840 remains responsible for application protocols, security, addressing policy, and connection management. This division is useful when BLE processing must coexist with frequent network activity. However, hardware offload alone does not guarantee deterministic application latency. SPI transfers, interrupt scheduling, firmware queues, and Ethernet congestion can still introduce delays. The W5500 also has practical limitations. Its hardware sockets are finite, its internal packet memory must be allocated carefully, and its offload engine supports IPv4 rather than native IPv6. For industrial installations, Ethernet cabling provides a controlled physical uplink, but switch reliability, cable integrity, and network configuration remain system-level concerns. ### 4. Implementation Notes #### Hardware interface The CSDN article proposes a direct SPI connection between the nRF52840 and W5500. The nRF52840 operates as the SPI controller, while the W5500 acts as the peripheral. | Signal | nRF52840 side | W5500 side | | --- | --- | --- | | SPI clock | SCK | SCLK | | SPI transmit | MOSI | MOSI | | SPI receive | MISO | MISO | | Chip select | GPIO output | SCSn | | Hardware reset | GPIO output | RSTn | | Network interrupt | GPIO interrupt input | INTn | | Supply | 3.3 V system | 3.3 V supply | The original article uses generic `P0.xx` placeholders rather than a completed pin assignment. Consequently, the actual GPIO mapping must be established using the selected development board's pinout and configuration. For a custom PCB, the W5500 also requires an appropriate 25 MHz clock circuit, Ethernet magnetics, and an RJ45 interface. The Ethernet layout and supply decoupling should follow the WIZnet reference design rather than relying on generic wiring assumptions. blog.csdn.net #### Firmware architecture The article proposes using Nordic's nRF Connect SDK with Zephyr RTOS, with software organized around BLE services, sensor acquisition, W5500 access, and network event processing. A suitable implementation sequence is: Initialize the nRF52840 SPI peripheral and the W5500 reset and interrupt GPIOs. Reset the W5500 and verify register communication. Confirm the Ethernet PHY link, assign network settings, and configure socket TX/RX memory. Establish TCP or UDP communication with the industrial server. Register BLE GATT services for local monitoring and configuration. Exchange validated messages between BLE, Ethernet, and application tasks using synchronized queues. These steps describe the intended architecture, not an executed firmware build. #### Source implementation details The article contains illustrative C and Zephyr configuration fragments. Two short examples demonstrate its intended approach. Example 1 — Zephyr configuration Source location: CSDN article, Section 3.1, `prj.conf` configuration example. ```plaintext CONFIG_SPI=y CONFIG_GPIO=y ``` These settings enable the SPI and GPIO subsystems necessary to communicate with the W5500 and handle its control signals. The complete firmware configuration will also depend on the Zephyr version, selected Ethernet driver, BLE subsystem, and device-tree definitions. Example 2 — Socket transmission Source location: CSDN article, Section 4.1, illustrative `tcp_send_data()` function. ```plaintext w5500_write_sock_reg(sn, Sn_CR, SEND); ``` This excerpt represents the final transmission command after a payload has been written to the W5500 TX buffer and the associated write pointer has been updated. Its significance is that the nRF52840 can request network transmission through a socket command instead of performing TCP packet construction in application firmware. It does not, by itself, establish that data transmission succeeded. blog.csdn.net #### Important technical corrections Some descriptions in the original article require correction before reuse in working firmware. SPI framing: Section 3.2 describes a four-byte command header. The actual W5500 SPI transaction uses a 16-bit offset address followed by an 8-bit control field, then the data phase. The article's illustrative register-write pseudocode should not be copied as a functioning driver. docs.wiznet.io Socket buffer registers: Section 3.2 refers to `TMSR` and `RMSR`. Those are not the W5500's per-socket buffer-allocation registers. The W5500 uses `Sn_TXBUF_SIZE` and `Sn_RXBUF_SIZE` for this purpose. docs.wiznet.io Driver integration: The article suggests that a Zephyr W5500 binding might need to be created. Current Zephyr documentation already lists `wiznet,w5500` as an SPI device-tree binding. An implementation should evaluate the existing driver before developing a custom register-access layer. Zephyr Project Documentation Secure communication: The W5500's hardware TCP/IP processing does not provide TLS encryption. Encrypted telemetry, authenticated commands, and secure firmware updates require additional software or an appropriate security architecture. No public source repository, completed schematic, reproducible build, or measured throughput data was identified from the original article. The examples above are excerpts from its technical discussion rather than evidence of tested firmware. ### 5. Practical Tips / Pitfalls - Begin SPI debugging at a conservative clock rate. Verify register access, chip-select timing, reset handling, and SPI modes 0 or 3 before increasing frequency. The W5500's maximum SPI capability is not automatically the maximum reliable board-level operating speed. - Check the PHY link before opening network connections. Inspect the W5500 `PHYCFGR` register and use link-state transitions to drive recovery. A configured IP address does not imply a working Ethernet cable. WIZnet Document System - Plan IP configuration explicitly. Use DHCP with lease renewal and timeout handling, or deploy unique static IP settings. The W5500 hardware does not eliminate the need for a DHCP client implementation. - Allocate hardware sockets and buffers according to traffic. The W5500 offers eight sockets and separate TX/RX memory allocation. Reserve capacity for telemetry, command handling, and infrastructure services such as DHCP or DNS when required. - Keep interrupt service routines short. An ISR should signal a network worker rather than perform long SPI transactions. BLE callbacks and Ethernet tasks should exchange messages through bounded queues to avoid blocking radio processing. - Implement bounded recovery and watchdog handling. TCP disconnections, unreachable servers, DHCP failures, and cable removal should trigger controlled retries with backoff. A watchdog should detect genuine task failures without masking persistent network faults. - Design for industrial electrical conditions. Use appropriate Ethernet magnetics, surge and ESD protection, robust supply decoupling, and careful differential-pair routing. Validate Ethernet behavior near motors, relays, and other EMI sources before deployment. ### 6. FAQ Q1. Why use the WIZnet W5500 with the nRF52840 for industrial IoT? The W5500 provides an Ethernet MAC, PHY, hardware TCP/IP processing, and internal packet buffers through SPI. The nRF52840 lacks a native Ethernet MAC, so W5500 offers an external wired networking interface without requiring the MCU to implement the complete TCP/IP processing path in software. This allows more CPU and RAM resources to remain available for BLE and application processing. Q2. How does the W5500 connect to the nRF52840? The devices communicate using SPI signals MOSI, MISO, SCK, and chip select, with additional GPIO connections recommended for reset and interrupt handling. Both devices operate in a 3.3 V system. The Ethernet interface additionally requires appropriate magnetics and an RJ45 connector. The actual GPIO assignment depends on the chosen nRF52840 board. Q3. What exactly does the W5500 do in this dual-mode IoT architecture? The W5500 handles wired TCP/UDP network communication with the industrial server, including socket operations and packet buffering. The nRF52840 manages BLE access, data acquisition, command processing, and coordination between local and remote interfaces. A command received through W5500 is not automatically forwarded to BLE; that behavior must be implemented in application firmware. Q4. Can beginners build an nRF52840 and W5500 node? A developer familiar with C, SPI, basic TCP/IP networking, and Nordic's development environment can build a prototype using development boards and an existing W5500 Ethernet module. A beginner should first establish reliable SPI communication, then implement Ethernet telemetry, and finally introduce BLE configuration. Building an industrial-grade custom PCB also requires Ethernet layout, power integrity, and EMC engineering experience. Q5. How does the W5500 compare with BLE and Wi-Fi in this project? BLE, Wi-Fi, and W5500-based Ethernet serve different communication requirements. | Consideration | W5500 Ethernet | BLE | Wi-Fi | | --- | --- | --- | --- | | Physical medium | Wired | Wireless | Wireless | | Typical role | Industrial uplink | Local setup and maintenance | Wireless network uplink | | TCP/IP handling | Hardware offload | Not native to BLE GATT | Depends on chipset and firmware | | Main limitation | Requires Ethernet infrastructure | Limited range and application bandwidth | RF interference and access-point dependency | | Design advantage | Stable wired link and offload | Low-power local connectivity | Flexible cable-free IP connectivity | The combination of BLE and W5500 is appropriate when local technician access and a continuously available wired uplink are both useful. Wi-Fi is a reasonable alternative when Ethernet cabling is impractical, but its reliability depends on RF conditions and infrastructure. Neither Ethernet nor Wi-Fi inherently guarantees application-level real-time deadlines. ### 7. Source Original article: [nRF52840 and W5500 Dual-Mode Bluetooth/Ethernet IoT Node — CSDN](https://blog.csdn.net/weixin_34195364/article/details/93458705?utm_source=chatgpt.com) Published: August 17, 2026 Author account: `weixin_34195364` Source type: Technical architecture article with illustrative firmware excerpts. Source license: No explicit software or article reuse license was verified. The page is marked as original content; that designation does not establish an open-source license. Technical references: [WIZnet W5500 product documentation](https://docs.wiznet.io/Product/Chip/Ethernet/W5500?utm_source=chatgpt.com) [W5500 Datasheet, version 1.1.0](https://docs.wiznet.io/img/products/w5500/W5500_ds_v110e.pdf?utm_source=chatgpt.com) [W5500 TCP operation and initialization](https://docs.wiznet.io/Product/Chip/Ethernet/W5500/Application/tcp?utm_source=chatgpt.com) [Zephyr device-tree bindings documentation](https://docs.zephyrproject.org/latest/build/dts/api/bindings.html?utm_source=chatgpt.com) ### 8. Tags #W5500 #WIZnet #nRF52840 #IndustrialIoT #Ethernet #BluetoothLE #BLE #SPI #TCPIP #ZephyrRTOS #NordicSemiconductor #IoTGateway ## nRF52840에서 WIZnet W5500을 활용해 BLE·이더넷 듀얼 모드 산업용 IoT 노드를 구현하는 방법은? ### 1. 프로젝트 개요 (Summary) nRF52840과 WIZnet W5500을 결합하면 Bluetooth Low Energy(BLE)를 통한 로컬 설정과 유선 이더넷을 통한 원격 데이터 수집 및 제어 기능을 갖춘 산업용 IoT 노드를 구성할 수 있습니다. nRF52840은 BLE 통신, 센서 데이터 처리 및 애플리케이션 로직을 담당하고, W5500은 SPI 인터페이스를 통해 하드웨어 기반 TCP/IP 통신을 처리합니다. 이러한 구조는 현장 유지보수용 무선 인터페이스와 산업용 네트워크 연결을 분리하여 MCU의 네트워크 처리 부담을 줄입니다. 원본 CSDN 기술 문서는 2026년 8월 17일 게시되었으며, 실제 완성된 하드웨어 구현보다는 시스템 아키텍처와 펌웨어 구현 예시를 중심으로 설명합니다. W5500 사용은 문서에 명시되어 있지만, 실행 가능한 전체 소스 저장소나 성능 측정 결과는 확인되지 않았습니다. ### 2. 프로젝트의 기능 (What the Project Does) 산업용 IoT 장비에서는 서로 다른 두 가지 네트워크 접근 방식이 필요할 수 있습니다. 현장 엔지니어는 스마트폰이나 유지보수 단말기로 장비 설정을 변경해야 하고, 중앙 서버는 장비에서 생성되는 센서 데이터를 지속적으로 수집하고 제어 명령을 전달해야 합니다. 이 프로젝트는 이러한 요구사항을 충족하기 위해 BLE와 유선 이더넷의 역할을 분리하는 구조를 제안합니다. #### 시스템 아키텍처 BLE 유지보수 앱 장비 설정 및 진단 산업용 중앙 서버 데이터 수집 및 제어 BLE / GATT Ethernet / TCP·UDP nRF52840 BLE, 애플리케이션 로직 및 센서 처리 WIZnet W5500 하드웨어 TCP/IP 및 Ethernet MAC/PHY nRF52840 ↔ W5500: SPI + GPIO 센서 및 액추에이터 측정값, 디지털 입력, 제어 출력 원본 기술 문서를 기반으로 재구성한 논리적 시스템 아키텍처입니다. 실제 검증된 회로 연결도는 아닙니다. #### 주요 데이터 흐름 센서에서 서버로의 데이터 전송 센서는 ADC, I²C, SPI 등의 인터페이스를 통해 측정값을 nRF52840으로 전달합니다. nRF52840은 데이터를 처리하고 패킷으로 구성한 후 SPI를 통해 W5500으로 전달합니다. W5500은 TCP 또는 UDP 소켓을 사용해 데이터를 유선 이더넷 네트워크로 송신합니다. 서버에서 장비로의 제어 명령 서버에서 전송한 메시지는 W5500의 수신 버퍼에 저장됩니다. W5500은 인터럽트를 통해 nRF52840에 수신 이벤트를 알릴 수 있습니다. nRF52840은 데이터를 읽고 명령의 유효성을 확인한 후 필요한 제어 작업을 실행합니다. BLE를 이용한 현장 유지보수 현장 엔지니어는 스마트폰으로 nRF52840의 BLE GATT 서비스에 접속할 수 있습니다. 원본 문서는 네트워크 상태 확인, 서버 설정, 센서 데이터 알림, 유지보수 명령 등을 위한 BLE Characteristic 구성을 제안합니다. 여기서 중요한 점은 BLE와 이더넷이 자동으로 서로의 데이터를 전달하는 구조가 아니라는 것입니다. 두 인터페이스 사이의 데이터 공유, 명령 전달, 상태 동기화는 애플리케이션 펌웨어에서 직접 구현해야 합니다. ### 3. WIZnet W5500의 역할 (Where WIZnet Fits) 이 시스템의 이더넷 컨트롤러는 WIZnet W5500입니다. W5500은 SPI 인터페이스로 MCU에 연결되며, IPv4 기반 네트워크 통신의 주요 처리를 하드웨어에서 수행합니다. ## 8개 하드웨어 소켓 ## 32 KB 내부 송수신 버퍼 ## 80 MHz 최대 SPI 클록 ## 10/100 이더넷 PHY (Mbps) #### 하드웨어 TCP/IP 오프로딩이 중요한 이유 nRF52840은 64 MHz Cortex-M4F 프로세서, 256 KB RAM, 1 MB Flash를 탑재한 MCU입니다. BLE 프로토콜 처리, 센서 데이터 수집, 애플리케이션 작업을 동시에 실행해야 하는 환경에서 소프트웨어 TCP/IP 스택까지 추가하면 CPU 처리량과 메모리 사용량이 증가할 수 있습니다. W5500은 TCP 연결 관리, 재전송, 체크섬 처리, 패킷 버퍼링과 같은 기능을 하드웨어에서 수행합니다. 따라서 MCU는 네트워크 프로토콜의 세부 처리보다 BLE 이벤트와 애플리케이션 로직에 더 많은 자원을 사용할 수 있습니다. 다만 W5500을 사용한다고 해서 시스템 전체의 지연시간이 일정하게 보장되는 것은 아닙니다. SPI 전송, RTOS 태스크 스케줄링, 인터럽트 처리, 네트워크 혼잡 등은 여전히 지연을 발생시킬 수 있습니다. #### 산업용 IoT에서의 적용 의미 W5500을 사용하는 구조는 다음과 같은 기술적 요구사항에 적합합니다. BLE 기능을 유지하면서 별도의 유선 TCP/IP 인터페이스를 추가해야 하는 경우 MCU RAM과 CPU 사용량을 제한해야 하는 경우 Wi-Fi 무선 환경에 의존하지 않는 네트워크 연결이 필요한 경우 센서 데이터 전송과 로컬 장비 설정 기능을 분리해야 하는 경우 W5500에는 8개의 하드웨어 소켓과 제한된 내부 패킷 메모리가 있으므로, 동시 연결 수와 트래픽 특성에 맞는 설계가 필요합니다. 또한 W5500은 IPv4 기반이므로 IPv6를 기본적으로 지원해야 하는 환경에서는 다른 제품 또는 네트워크 구성을 검토해야 합니다. ### 4. 구현 방법 (Implementation Notes) #### 하드웨어 연결 원본 문서는 nRF52840과 W5500을 SPI 인터페이스로 연결하는 방식을 제안합니다. | 신호 | nRF52840 | W5500 | | --- | --- | --- | | SPI Clock | SCK | SCLK | | SPI 송신 | MOSI | MOSI | | SPI 수신 | MISO | MISO | | Chip Select | GPIO 출력 | SCSn | | Reset | GPIO 출력 | RSTn | | Interrupt | GPIO 인터럽트 입력 | INTn | | 전원 | 3.3 V 시스템 | 3.3 V | 원본 문서의 GPIO 설정은 `P0.xx` 형태의 일반적인 예시이므로 실제 보드에서 사용할 핀 번호는 별도로 정해야 합니다. 커스텀 PCB를 설계하는 경우에는 W5500용 25 MHz 클록 회로, 이더넷 마그네틱스, RJ45 커넥터 및 적절한 전원 디커플링이 필요합니다. #### 펌웨어 구조 원본 문서는 Nordic nRF Connect SDK와 Zephyr RTOS를 활용하는 개발 구조를 제안합니다. 구현 순서는 다음과 같이 구성할 수 있습니다. nRF52840의 SPI와 W5500의 Reset 및 Interrupt GPIO를 초기화합니다. W5500을 리셋하고 레지스터 접근이 정상적으로 이루어지는지 확인합니다. 이더넷 PHY 링크를 확인하고 IP 주소와 소켓 버퍼를 설정합니다. 산업용 서버와 TCP 또는 UDP 통신을 설정합니다. 로컬 설정 및 모니터링을 위한 BLE GATT 서비스를 등록합니다. BLE, Ethernet, 애플리케이션 태스크 사이에서 데이터를 전달할 큐와 동기화 로직을 구성합니다. 이는 원본 문서가 제안하는 시스템 구조를 바탕으로 정리한 구현 절차이며, 완성된 펌웨어의 실행 결과를 의미하지 않습니다. #### 원본 코드 분석 원본 CSDN 문서에는 Zephyr 설정과 W5500 소켓 통신을 설명하는 C 코드가 포함되어 있습니다. 예제 1 — Zephyr 주변장치 설정 출처: 원본 문서 Section 3.1, `prj.conf` ```plaintext CONFIG_SPI=y CONFIG_GPIO=y ``` 이 설정은 W5500과 통신하는 SPI 주변장치 및 제어 신호 처리를 위한 GPIO 서브시스템을 활성화합니다. 실제 프로젝트에서는 사용하는 Zephyr 버전과 드라이버에 따라 추가적인 Kconfig 및 DeviceTree 설정이 필요합니다. 예제 2 — W5500 소켓 전송 명령 출처: 원본 문서 Section 4.1, `tcp_send_data()` 예시 ```plaintext w5500_write_sock_reg(sn, Sn_CR, SEND); ``` 이 명령은 소켓 송신 버퍼에 데이터를 기록하고 송신 포인터를 갱신한 후, W5500에 데이터 전송을 요청하는 역할을 합니다. 이러한 방식에서는 MCU가 TCP 패킷을 직접 구성하는 대신 W5500의 하드웨어 소켓 기능을 이용할 수 있습니다. 단, 이 명령의 실행만으로 전송 성공이 보장되지는 않습니다. 소켓 상태와 관련 인터럽트 또는 완료 상태를 확인해야 합니다. #### 구현 시 주의할 원본 문서의 기술적 차이 원본에는 실제 W5500 드라이버와 일치하지 않는 설명도 포함되어 있습니다. SPI 프레임 구조 원본 Section 3.2에서는 4바이트 명령 헤더를 설명하지만, W5500 SPI 통신에서는 16비트 주소 필드와 8비트 제어 필드를 사용하는 3바이트 헤더 구조가 적용됩니다. 따라서 원본의 의사코드를 그대로 레지스터 드라이버로 사용해서는 안 됩니다. 소켓 버퍼 설정 원본에서 언급된 `TMSR`, `RMSR`은 W5500의 소켓별 버퍼 할당 레지스터가 아닙니다. W5500에서는 `Sn_TXBUF_SIZE`와 `Sn_RXBUF_SIZE`를 통해 각 소켓의 송수신 버퍼 크기를 설정합니다. Zephyr 드라이버 현재 Zephyr에는 `wiznet,w5500` DeviceTree 바인딩이 제공됩니다. 따라서 W5500 전용 드라이버를 처음부터 구현하기보다, 사용 중인 Zephyr 버전의 드라이버 지원 범위를 우선 확인하는 것이 합리적입니다. 보안 기능 W5500의 TCP/IP 하드웨어 오프로딩에는 TLS 암호화 기능이 포함되지 않습니다. 산업용 서버 인증, 암호화된 데이터 전송, 안전한 펌웨어 업데이트가 필요하다면 별도의 소프트웨어 보안 계층이나 보안 아키텍처가 필요합니다. ### 5. 실무 구현 팁 및 주의사항 (Practical Tips / Pitfalls) SPI 속도는 낮게 시작합니다. 초기에는 보수적인 SPI 클록으로 레지스터 접근, CS 타이밍, Reset 동작을 확인합니다. SPI Mode 0 또는 3의 정상 동작을 검증한 뒤 속도를 높이는 것이 좋습니다. 네트워크 연결 전에 PHY 링크를 확인합니다. `PHYCFGR` 레지스터를 통해 링크 상태를 확인하고, 케이블 연결 해제나 재연결을 별도 이벤트로 처리해야 합니다. IP 주소 설정 방식을 명확히 합니다. DHCP를 사용할 경우 임대 갱신과 타임아웃 처리가 필요하며, 고정 IP를 사용할 경우 중복 주소가 발생하지 않도록 관리해야 합니다. 소켓과 내부 버퍼를 계획적으로 할당합니다. 8개의 하드웨어 소켓과 32 KB의 내부 메모리를 텔레메트리, 제어 명령, DHCP 및 기타 네트워크 서비스 요구사항에 맞게 배분합니다. 인터럽트 처리 시간을 짧게 유지합니다. W5500 인터럽트 안에서 긴 SPI 통신을 수행하기보다 네트워크 태스크에 이벤트를 전달하는 구조가 BLE 동작과의 충돌을 줄이는 데 유리합니다. 복구 로직과 Watchdog을 설계합니다. 서버 연결 실패, DHCP 오류, 네트워크 단절 발생 시 무한 반복 대신 재시도 간격과 복구 조건을 명확히 해야 합니다. 산업 환경의 EMI와 전원 안정성을 고려합니다. 이더넷 마그네틱스, ESD 및 서지 보호, 전원 디커플링, 차동 신호 라우팅을 적절히 설계하고 모터와 릴레이 주변에서 실제 통신 안정성을 시험해야 합니다. ### 6. FAQ #### Q1. 산업용 IoT에서 nRF52840과 W5500을 함께 사용하는 이유는 무엇인가요? W5500은 Ethernet MAC/PHY와 하드웨어 TCP/IP 스택, 내부 패킷 버퍼를 제공하는 이더넷 컨트롤러입니다. nRF52840에는 기본 이더넷 MAC이 없으므로 W5500을 사용하면 SPI 기반으로 유선 네트워크 기능을 추가할 수 있습니다. 또한 TCP/IP 프로토콜의 주요 처리를 W5500이 담당하므로 nRF52840은 BLE 이벤트와 센서 데이터 처리에 더 많은 자원을 활용할 수 있습니다. #### Q2. W5500을 nRF52840에 어떻게 연결하나요? W5500은 SPI 인터페이스를 사용해 nRF52840에 연결됩니다. 기본 연결에는 MOSI, MISO, SCK, CS 신호가 필요하며 Reset과 Interrupt를 위한 GPIO 연결도 권장됩니다. 두 장치는 3.3 V 시스템에서 동작합니다. 실제 GPIO 핀 번호는 사용하는 nRF52840 개발 보드에 맞게 지정해야 합니다. #### Q3. 이 프로젝트에서 W5500은 구체적으로 어떤 역할을 하나요? W5500은 산업용 중앙 서버와의 유선 TCP/UDP 통신을 담당합니다. nRF52840이 처리한 센서 데이터는 SPI를 통해 W5500으로 전달되고, W5500은 이를 이더넷 네트워크로 전송합니다. 반대로 서버에서 수신한 제어 명령은 W5500을 거쳐 nRF52840으로 전달됩니다. BLE와 이더넷 간 메시지 전달은 애플리케이션 펌웨어에서 별도로 구현해야 합니다. #### Q4. 초보 개발자도 nRF52840과 W5500으로 IoT 노드를 구현할 수 있나요? C 언어, SPI 통신, TCP/IP 네트워크 및 Nordic 개발 환경에 대한 기본 지식이 있다면 개발 보드를 활용해 프로토타입을 제작할 수 있습니다. 처음에는 W5500의 SPI 레지스터 접근을 확인하고, 그다음 이더넷을 통한 센서 데이터 전송을 구현하는 것이 좋습니다. 이후 BLE GATT 서비스를 추가하면 두 네트워크 인터페이스의 동작을 단계적으로 검증할 수 있습니다. 다만 실제 산업용 PCB를 제작하려면 이더넷 회로 설계, 전원 무결성, EMC 대응에 대한 추가적인 경험이 필요합니다. #### Q5. W5500을 사용하는 이더넷 방식은 BLE 및 Wi-Fi와 어떻게 다른가요? 세 기술은 서로 다른 통신 요구사항에 적합합니다. | 비교 항목 | W5500 Ethernet | BLE | Wi-Fi | | --- | --- | --- | --- | | 전송 매체 | 유선 | 무선 | 무선 | | 주요 역할 | 산업용 네트워크 연결 | 로컬 설정 및 유지보수 | 무선 네트워크 연결 | | TCP/IP 처리 | 하드웨어 오프로딩 | GATT 자체는 TCP/IP 미사용 | 칩셋 및 펌웨어에 따라 다름 | | 주요 제약 | 유선 인프라 필요 | 통신 거리 및 대역폭 제약 | RF 간섭과 AP 환경의 영향 | | 설계상 장점 | 유선 연결 및 CPU 오프로딩 | 저전력 근거리 통신 | 케이블 없는 IP 연결 | 이 프로젝트에서는 BLE를 로컬 유지보수 인터페이스로 사용하고 W5500을 서버 연결 인터페이스로 사용하는 구성이 기술적으로 타당합니다. Wi-Fi는 이더넷 케이블 설치가 어려운 환경에서 대안이 될 수 있지만, RF 환경과 무선 인프라 상태에 영향을 받습니다. 유선 이더넷 역시 애플리케이션 수준의 실시간 응답을 자동으로 보장하지는 않습니다. ### 7. 출처 (Source) 원본 문서: [CSDN — nRF52840 및 W5500 기반 Bluetooth/Ethernet 듀얼 모드 IoT 노드](https://blog.csdn.net/weixin_34195364/article/details/93458705?utm_source=chatgpt.com) 게시일: 2026년 8월 17일 작성자 계정: `weixin_34195364` 자료 형태: 펌웨어 예시가 포함된 기술 아키텍처 문서 라이선스: 명시적인 소프트웨어 또는 문서 재사용 라이선스는 확인되지 않았습니다. 원본 문서의 독창적 콘텐츠 표시는 오픈소스 라이선스를 의미하지 않습니다. #### 관련 기술 문서 [WIZnet W5500 공식 제품 문서](https://docs.wiznet.io/Product/Chip/Ethernet/W5500?utm_source=chatgpt.com) [W5500 데이터시트 v1.1.0](https://docs.wiznet.io/img/products/w5500/W5500_ds_v110e.pdf?utm_source=chatgpt.com) [W5500 TCP 동작 및 초기화 문서](https://docs.wiznet.io/Product/Chip/Ethernet/W5500/Application/tcp?utm_source=chatgpt.com) [Zephyr DeviceTree 바인딩 문서](https://docs.zephyrproject.org/latest/build/dts/api/bindings.html?utm_source=chatgpt.com) ### 8. 태그 (Tags) #W5500 #WIZnet #nRF52840 #IndustrialIoT #Ethernet #BluetoothLE #BLE #SPI #TCPIP #ZephyrRTOS #NordicSemiconductor #IoTGateway --- Source: https://maker.wiznet.io/gavinchang/projects/how-to-build-a-dual-mode-industrial-iot-node-with-wiznet-w5500-on-nrf52840/