Wiznet makers

josephsr

Published April 08, 2026 ©

109 UCC

13 WCC

13 VAR

0 Contests

0 Followers

0 Following

Original Link

SPI-Based Network Offload for Dual-Stack UDP on Cortex-M4

A Cortex-M4 controller offloads wired Ethernet and dual-stack UDP handling to W6100 over SPI to reduce software stack burden and stabilize embedded network.

COMPONENTS
PROJECT DESCRIPTION

Overview
This patent describes a wired networking path built around three main blocks: a Cortex-M4-class processor, a network controller centered on the WIZnet W6100 hardwired TCP/IP chip, and a power stage that converts 24 V input into the 3.3 V rail needed by the logic. The figures and claims show the processor handling application-layer data, the W6100-side network controller handling Ethernet-facing communication, and the line interface being completed through a transformer and RJ45 connector.

Main Content

Image generated by gpt


The operating method is intentionally narrow. The sequence starts with GPIO and SPI configuration, then resets the W6100, loads IPv4 and IPv6 network settings, assigns socket buffers, checks PHY link state, opens SOCKET0 in UDP dual mode, writes payloads into the transmit buffer with pointer updates, receives packets through PACKINFO parsing, updates receive pointers, and finally closes the socket. Figure 12 reduces the whole design to an open -> receive or send -> completion or timeout -> close loop, which shows that the patent is aiming for a bounded embedded transport path rather than a general-purpose network endpoint.

System Context
The networking path is not the system’s primary mission. In the patent narrative, it sits inside an alignment-information processing and distribution device, where the processor performs calculation and device logic while the network side periodically sends alignment-support information to UDP clients. The stated contrast with a traditional software TCP/IP stack is lower interrupt pressure, reduced memory burden, and better communication stability once the device is networked.

Architecture / Design Considerations
The most important wired-Ethernet design choice is the use of WIZnet W6100 as the boundary device between application logic and the LAN. W6100 is a hardwired TCP/IP controller with integrated 10/100 Ethernet MAC and PHY, IPv4/IPv6 dual-stack support, eight hardware sockets, and SPI host access, and the patent uses exactly those properties to keep the processor on the application side of the interface rather than making it own the full network stack. In this system, WIZnet W6100 is not a replaceable generic Ethernet mention. It is the component that turns the MCU side into a register, buffer, and command client for wired Ethernet.

There is also a revealing ambiguity in the patent language. It repeatedly calls the interface a “GPIO-simulated SPI controller,” but the detailed method configures SPI registers, frame length, clock polarity and phase, prescaling, software NSS handling, and alternate-function pins in a way that reads more like use of a conventional MCU SPI peripheral than pure bit-banged GPIO emulation. That makes the practical design story look less like a new SPI invention and more like a system-level composition of MCU, W6100 offload networking, and a stable operating sequence.

Possible Implications
The highest-cost failure points are concentrated at the boundaries. If PHY link state is not confirmed before socket work begins, if SEND and RECV completion or timeout handling is wrong, or if transmit and receive pointer bookkeeping is incorrect, the design can fail at the exact places where packet delivery depends on correct buffer discipline. The patent gives these steps unusual procedural weight, which is usually a good indicator of where integration pain actually lives.

Removing individual components changes the character of the whole system. Remove W6100 and it stops being a hardwired-stack Ethernet offload path. Remove the transformer and RJ45 path and it stops being the same wired Ethernet endpoint. Remove the UDP dual-mode setup and the method loses the specific dual-stack send and receive loop that defines the patent’s transport behavior. This is especially notable because STM32F469xx devices can provide their own 10/100 Ethernet MAC, so the patent appears to prefer offloaded protocol handling and command-driven integration over a more MCU-owned Ethernet design.

Conclusion
This patent is best read as a system-integration pattern, not a new theory of networking. Its value lies in packaging a predictable wired Ethernet path around WIZnet W6100 so that a Cortex-M4 controller can stay focused on application computation and device logic while network transport is narrowed into a more controllable SPI-and-buffer workflow.

 

전체 개요

이 특허는 MCU가 네트워크 프로토콜을 전부 소프트웨어로 떠안는 구조를 피하고, 계산과 장치 제어는 Cortex-M4 계열 처리기 쪽에 남겨 두면서, 유선 Ethernet과 TCP/IP 계층 상당 부분은 W6100 기반 네트워크 제어부로 넘기는 설계로 보시면 됩니다. 도면을 보면 큰 뼈대는 처리기 - W6100 기반 네트워크 제어부 - 네트워크 변압기 - RJ45이고, 그 아래를 24V 입력 -> 5V -> 3.3V 전원부가 받쳐 주는 형태입니다.

문제의식과 기술적 맥락 재구성

배경 설명의 초점은 꽤 노골적입니다. 기존 방식은 MCU 안에 소프트웨어 TCP/IP 스택을 올려 통신까지 같이 처리하므로 인터럽트 응답, 클록 자원, 메모리 부담이 커지고, 스레드가 늘수록 통신 품질이 떨어질 수 있으며, 네트워크 공격에 대한 부담도 커진다고 봅니다. 그래서 이 특허는 “계산하는 프로세서”와 “네트워크를 상대하는 칩”의 역할을 나누고, 특히 정렬 정보 처리·분배 장치처럼 주기적으로 UDP 데이터를 내보내는 장비형 시스템에 맞춘 경로를 만들려는 쪽입니다.

기술 흐름 설명

Image generated by gpt
  1. 먼저 전원 경로를 고정합니다. 24V 입력을 LM2675와 LM1117의 2단 전원 구조로 3.3V까지 내리고, 그 전압으로 처리기와 네트워크 제어부를 함께 구동합니다. 이 단계가 빠지면 뒤의 통신 절차는 의미가 없어집니다. 
  2. 그다음 처리기 쪽에서 SPI 관련 핀과 레지스터를 설정합니다. 특허에는 PB13, PB14, PB15, PD07, PD08 등의 핀 설정과 함께 SPI 데이터 모드, 마스터 모드, 16비트 프레임, 클록 극성/위상, 소프트웨어 NSS 관리, 분주비, CRC 설정까지 순서대로 적혀 있습니다. 즉 네트워크는 나중 문제이고, 먼저 MCU가 W6100을 안정적으로 지배할 수 있는 제어면을 세우는 단계입니다. 
  3. 이후 PD08을 통해 W6100을 리셋하고, MAC 주소, IPv4 주소, IPv6 주소, 게이트웨이, 서브넷, 재전송 시간, 재전송 횟수, 소켓 버퍼 크기를 설정합니다. 여기서 눈에 띄는 점은 네트워크를 잠금과 해제로 관리하는 절차가 별도로 있다는 점인데, 단순 연결보다 “초기화 후 고정된 상태로 운용”하려는 성격이 강합니다. 
  4. 링크가 붙었는지 확인한 뒤에야 SOCKET0를 W6100의 UDP dual mode로 엽니다. 특허가 보여 주는 운용은 범용 멀티소켓 서버가 아니라, IPv4와 IPv6를 한 소켓 흐름 안에서 구분해 송수신하는 좁고 통제된 경로입니다. 송신은 TX 버퍼에 데이터를 쓰고 write pointer를 갱신한 다음 SEND 또는 IPv6 SEND를 걸고, 수신은 PACKINFO를 읽어 UDP4인지 UDP6인지 구분한 뒤 RECV로 버퍼를 갱신합니다. 
  5. 마지막은 종료 조건 관리입니다. 전송 완료, 수신 여부, 타임아웃, CLOSE 명령이 전부 명시되어 있어서, 이 특허는 “한 번 연결되면 알아서 돌아간다”는 류가 아니라 상태 전이를 계속 확인하는 운영형 설계에 가깝습니다. 이런 문서는 늘 친절한 척하지만 결국 디버깅 지옥이 숨어 있는 위치를 스스로 알려 줍니다. 

왜 이런 구조가 나왔는지에 대한 해설

이 구조의 핵심 차이는 기존 접근과 달리 네트워크를 MCU 내부 소프트웨어 문제로 보지 않는다는 데 있습니다. 특허는 소프트웨어 스택 방식의 부담을 줄이겠다는 문제의식에서 출발하고, 실제 구현도 W6100을 경계 장치로 세워 MCU가 버퍼와 명령 중심으로만 네트워크를 다루게 만듭니다. 즉 여기서 Ethernet 경로는 시스템의 주역이라기보다, 정렬·보정 계산 결과를 일정한 방식으로 밖에 내보내기 위한 보조 수단으로 배치되어 있습니다.

또 하나는 전원 조건입니다. 24V 입력을 받아 3.3V 로직 전원으로 내리는 회로를 별도 청구항으로 끌고 간다는 점은, 이 설계가 순수 소프트웨어 예제가 아니라 실제 장비 내부 모듈로 들어가는 보드 구성을 꽤 의식하고 있음을 보여 줍니다. 다시 말해 “네트워크 기능만 있는 칩 사용법”보다 “장비에 들어가는 통신 서브시스템” 쪽에 가깝습니다.

문헌 표현상 ‘GPIO 모의 SPI 제어기’라고 부르는 부분도 흥미롭습니다. 그런데 상세 절차를 보면 SPI_CR1, SPI_CR2, SPI_SR, 마스터 모드, 클록 위상/극성, 대체 기능 핀 설정이 전면에 나와서, 순수한 비트뱅잉 GPIO라기보다 MCU의 SPI 주변장치를 GPIO 핀에 실어 운용하는 구조로 읽는 편이 더 자연스럽습니다. 이 해석은 추론임을 분명히 말씀드립니다.

설계 선택의 배경, 제약 조건, 대안 가능성

가장 흥미로운 지점은 STM32F469xx 계열 자체가 10/100 Ethernet MAC를 제공한다는 점입니다. 그럼에도 이 특허는 MCU 자체 MAC 중심 구조로 가지 않고, W6100 하드웨어 TCP/IP 오프로딩 구조를 택합니다. 따라서 이 설계는 MAC 레벨의 유연성보다 프로토콜 처리 부담의 외부화, 검증 범위 축소, 그리고 명령/버퍼 기반 운용의 예측 가능성을 더 중시한 것으로 해석됩니다. 이 부분은 추론임입니다.

대안 구조는 적어도 하나는 분명합니다. MCU 내부 Ethernet MAC와 외부 PHY를 사용하고, 그 위에 소프트웨어 TCP/IP 스택을 올리는 방식입니다. 하지만 그 경우 프로토콜 처리 책임이 다시 MCU 쪽으로 넘어오고, 특허가 줄이려고 했던 인터럽트·메모리·소프트웨어 복잡도 문제가 다시 커질 가능성이 있습니다.

그리고 W6100은 공식 문서상 8개의 하드웨어 소켓을 제공하지만, 이 특허의 절차는 거의 전부 SOCKET0 하나의 UDP dual mode 흐름에 집중합니다. 칩이 가진 확장성 전체를 밀어붙이기보다, 먼저 하나의 검증된 송수신 경로를 안정화하려는 성격이 강하다고 보는 편이 맞겠습니다. 이 역시 추론임입니다.

생소한 개념에 대한 풀어쓴 설명

하드웨어 TCP/IP 스택은 네트워크 프로토콜 처리를 MCU 소프트웨어가 다 하지 않고, 전용 칩 안에 상당 부분을 넣어 둔 방식입니다. 그래서 MCU는 프레임 전체를 직접 만지기보다 레지스터를 설정하고 버퍼를 읽고 쓰고 SEND/RECV 같은 명령을 내리는 쪽으로 역할이 바뀝니다.

MAC, PHY, 네트워크 변압기, RJ45는 역할이 다릅니다. MAC는 Ethernet 프레임 규칙을 다루는 계층이고, PHY는 전기 신호 변환과 링크 상태를 담당하며, 네트워크 변압기는 절연과 신호 결합을 돕고, RJ45는 실제 케이블과 연결되는 물리 단자입니다. 특허 도면은 이 네 요소를 W6100에서 케이블까지 이어지는 유선 경로로 분리해서 보여 줍니다.

UDP dual mode와 PACKINFO는 이 특허의 실제 운용 감각을 보여 주는 대목입니다. 한 소켓에서 IPv4 UDP와 IPv6 UDP를 모두 다루고, 수신 후 PACKINFO를 보고 패킷 종류와 상대 주소/포트를 구분하므로, 범용 네트워크 스택보다는 “정해진 형식의 데이터를 안정적으로 주고받는 운용 루프”에 가깝습니다.

네트워크 잠금 절차는 본문상 해제 후 설정, 다시 잠금 순서로 나타납니다. 이는 운용 중 임의 변경 가능성을 줄이고 초기 설정 상태를 더 엄격히 관리하려는 의도로 읽힙니다. 이 해석은 추론임입니다.

시스템 구성 및 선택지 해석

이 특허에서 특정 구성요소를 빼면 시스템 성격이 바로 달라집니다. W6100을 제거하면 하드웨어 TCP/IP 오프로딩 경계가 사라지고, 설계는 MCU 주도형 Ethernet 구조로 바뀝니다. UDP dual mode를 빼면 이 특허가 강조하는 IPv4/IPv6 동시 운용 루프가 흐려지고, 변압기와 RJ45를 빼면 애초에 같은 유선 Ethernet 엔드포인트라고 보기 어렵습니다.

현실적인 채택 조건도 비교적 분명합니다. 유선 LAN을 쓰고, 주기적인 UDP 데이터 전송이 있고, 24V 전원 환경 속에서 MCU 자원을 아끼고 싶으며, 네트워크 동작을 소프트웨어로 광범위하게 바꾸기보다 검증 가능한 경로를 선호하는 장비형 임베디드 시스템에 더 잘 맞습니다. 반대로 네트워크 기능을 소프트웨어로 세밀하게 계속 확장해야 하는 경우라면 제약이 빨리 드러날 수 있습니다. 후반부는 추론임입니다.

내부 관점에서의 시사점

실패 비용이 가장 큰 구간은 세 곳입니다. 첫째, PHY 링크를 확인하지 않은 채 소켓 절차로 들어가는 구간입니다. 둘째, 송수신 버퍼의 read/write pointer를 갱신하는 구간입니다. 셋째, SEND/RECV 완료와 타임아웃을 판정하는 상태 전이 구간입니다. 이 셋은 통신 자체보다 “통신이 되는 것처럼 보이는데 데이터가 꼬이는” 장애를 만들기 쉬운 위치입니다.

오해가 생기기 쉬운 연결부도 분명합니다. MCU <-> SPI <-> W6100 경계에서는 설정값과 타이밍 해석이 문제이고, W6100 <-> 변압기 <-> RJ45 경계에서는 링크 성립과 물리층 연결성이 문제이며, 수신 이후 PACKINFO -> UDP4/UDP6 demux -> 상위 데이터 처리 경계에서는 데이터 의미 해석이 문제입니다. 이 특허는 겉으로는 통신 특허 같지만, 실제로는 경계 관리 특허에 더 가깝습니다. 마지막 문장은 추론임입니다.

FAQ

Q1. 기존 접근 대비 이 특허의 핵심 차별점은 무엇인가요?
핵심 차별점은 MCU 내부에서 소프트웨어 TCP/IP 스택을 돌리는 대신, W6100에 프로토콜 처리를 맡기고 MCU는 상위 데이터 처리와 장치 로직에 더 집중하게 만든 점입니다. 또 칩 자체는 8소켓을 지원하지만, 특허의 실제 방법은 SOCKET0 기반 UDP dual mode에 집중해서 경로를 훨씬 더 좁고 관리 가능하게 잡고 있습니다.

Q2. 이 특허의 중심은 정말 ‘GPIO로 SPI를 흉내 내는 것’인가요?
문헌은 그렇게 부르지만, 절차를 보면 SPI 레지스터와 SPI 동작 모드, 대체 기능 핀 설정이 중심이라서 완전한 의미의 순수 GPIO 비트뱅잉만을 핵심으로 보기는 어렵습니다. 실질 가치는 MCU, W6100, 전원, 유선 Ethernet, UDP dual mode 운용 절차를 하나의 통합 패턴으로 묶어 놓은 데 있다고 보는 편이 더 설득력 있습니다. 후반부 해석은 추론임입니다.

Q3. 이 시스템에서 실패 비용이 가장 큰 판단 지점은 어디인가요?
PHY 링크를 확인하지 않은 채 소켓을 여는 순간, TX/RX pointer를 갱신하는 순간, SEND/RECV 완료와 타임아웃을 처리하는 순간입니다. 여기서 틀리면 케이블은 꽂혀 있고 칩도 살아 있는데 데이터만 손실되거나 멈추는 형태가 나와서, 현장 디버깅 비용이 급격히 커집니다.

Q4. 왜 TCP가 아니라 UDP dual mode를 전면에 두었나요?
특허 배경은 정렬 지원 정보를 주기적으로 UDP 클라이언트에 보내는 장치 맥락을 전제로 합니다. 따라서 연결 유지 로직이 무거운 일반 TCP 경로보다, IPv4/IPv6를 한 소켓 흐름에서 구분해 빠르게 송수신하는 UDP dual mode가 목적에 더 맞았을 가능성이 큽니다. 두 번째 문장은 추론임입니다.

Q5. W6100을 빼면 시스템 성격이 어떻게 바뀌나요?
그 순간 이 특허의 핵심인 하드웨어 TCP/IP 오프로딩 경계가 사라집니다. 이후에는 MCU가 자체 Ethernet MAC와 외부 PHY 또는 다른 구조를 통해 더 많은 네트워크 책임을 져야 하므로, 구현 난이도와 장애 양상이 완전히 달라집니다.

Q6. 왜 STM32F469 계열을 썼을 가능성이 있나요?
특허 본문은 Cortex-M4의 효율성과 사용 용이성을 강조하고, ST는 STM32F469xx를 최대 180 MHz Cortex-M4, FPU, 풍부한 I/O와 통신 인터페이스를 가진 MCU로 설명합니다. 그래서 계산과 장치 제어는 MCU가 맡고, 네트워크는 외부 칩에 넘기는 역할 분담이 목적에 잘 맞았을 가능성이 있습니다. 마지막 문장은 추론임입니다.

저자 정보

张珊珊, 庞志超, 刘真晖는 이 특허의 발명자로 기재되어 있습니다. 특허 명의는 당시 중국선박중공그룹(CSIC) 제707연구소로 적혀 있지만, 2019년 그룹 통합 이후에는 현재의 중국선박그룹 체계 맥락에서 이해하는 편이 자연스럽습니다. 공개된 중국선박그룹 소개에 따르면 이 그룹은 해군 무기체계의 연구·설계·생산·시험·보장을 담당하는 대형 국유 조선·방산 그룹이고, 최근 707연구소 관련 공개 자료에서는 항법, 조종·제어, 해양환경 기술을 중점 방향으로 언급하고 있습니다.

개별 발명자들의 세부 경력이나 현재 직무는 공개된 범위가 제한적입니다. 그래서 이 특허에서는 세 사람을 707연구소 소속의 임베디드 통신·제어 계열 실무 연구자 또는 엔지니어 집단으로 보는 정도가 가장 안전합니다. 이 마지막 해석은 추론임이며, 개인별 이력은 정보 제한이 있습니다.

Documents
Comments Write