Wiznet makers

Project Overview

zweidraehte is a conformance-oriented KNX device-side protocol stack written in Rust. Its allocation-free no_std core is designed to run on both bare-metal microcontrollers and embedded Linux without replacing the core protocol implementation. Device configurations, link media, interface objects, storage backends, and optional services are selected through compile-time trait composition rather than runtime registries or dynamic dispatch.

The project covers more than the KNX runtime stack. It also includes:

• KNX TP1, KNX-RF, KNXnet/IP, USB HID, and composite KNX/IP-to-TP1 link layers
• KNX Data Secure and KNX IP Secure components
• ETS parameter and communication-object definitions written through Rust macros
• MTXML and signed .knxprod product-database generation
• Device provisioning, conformance testing, bus-monitoring, and product-data comparison tools
• Reference firmware for STM32G0, RP2040, Raspberry Pi Pico W, and embedded Linux targets

The repository describes the implementation as a work in progress. Its internal conformance suite exercises substantial portions of the published KNX test specifications, but the stack has not received official KNX Association certification or validation using the official EITT test environment.

Project Type

The stack uses synchronous KNX network, transport, and application-layer processing driven by an asynchronous router loop. Hardware link layers run as separate async tasks, using Embassy on embedded targets and standard executors on Linux.

System Architecture

Device Definition and ETS DSL
        │
        ├── Parameters
        ├── Communication Objects
        ├── ETS UI Pages
        └── Interface Objects
        │
        ▼
Compile-Time Rust Composition
        │
        ├── System B BCU Profile
        ├── Security Extensions
        ├── Storage Backend
        ├── Application Services
        └── Selected Link Medium
        │
        ▼
KNX Device Stack
        │
        ├── Application Layer
        ├── Transport Layer
        ├── Network Layer
        └── Async Message Router
        │
        ▼
Link-Layer Implementation
        │
        ├── KNX TP1 / TP-UART
        ├── KNX-RF
        ├── KNXnet/IP
        ├── USB HID
        └── KNX/IP ↔ TP1 Composite Interface
        │
        ▼
Physical Hardware or Linux Network Interface

The workspace is divided into protocol definitions, device-stack implementation, procedural macros, ETS tooling, product-package generation, platform abstractions, host-side tools, conformance tests, and target-specific firmware.

Major Software Components

Reference Hardware and Firmware

STM32G0 Targets

The STM32G0 firmware includes TP1 light switches, Data Secure variants, KNX-RF devices, and an RF retransmitter. TP1 communication supports TP-UART-class transceivers such as TP-UART 2, NCN5120, and E981.03.

RP2040 Targets

The RP2040 workspace contains separate firmware projects for:

• W5500 Ethernet KNX/IP light switch
• W5500 Ethernet KNX IP Secure light switch
• W5500 Ethernet-to-TP1 KNX/IP interface
• Pico W Wi-Fi KNX/IP light switch
• TP1 light switch

The Ethernet and Wi-Fi implementations are separate firmware targets rather than concurrent interfaces in one device image.

WIZnet Product Usage

WIZnet Product Role: Confirmed

Product: WIZnet W5500 Ethernet Controller

The W5500 is used by the RP2040 Ethernet firmware as the physical Ethernet interface for KNXnet/IP communication. The confirmed W5500 targets include the Ethernet light switch, Ethernet secure light switch, and KNX/IP-to-TP1 interface.

The reference wiring in the RP2040 Ethernet light-switch firmware is:

SPI0 is configured for 50 MHz operation. The driver is initialized through embassy-net-wiznet, while a dedicated Embassy task continuously runs the W5500 device driver.

W5500 Network Path

RP2040 Application
        │
        ▼
zweidraehte KNXnet/IP Link Layer
        │
        ▼
UDP/TCP Abstraction and Socket Pools
        │
        ▼
embassy-net Software Network Stack
        │
        ▼
embassy-net-wiznet Driver
        │
        ▼
W5500 MACRAW Interface
        │
        ▼
Ethernet Network

The firmware creates an embassy-net network stack above the W5500 device, performs DHCP or applies stored static IPv4 settings, and then supplies UDP and TCP socket contexts to the KNXnet/IP layer.

TOE Usage

TOE Usage: No

The project does not use the W5500 hardware TCP/IP socket engine as a conventional TCP/IP Offload Engine.

The embassy-net-wiznet driver explicitly operates supported WIZnet chips in MACRAW mode. Ethernet frames are transferred through the W5500, while IPv4, DHCP, UDP, TCP, multicast, and socket management are implemented by the MCU-side embassy-net software stack.

Therefore, the implementation path is classified as:

Framework/driver path:
embassy-net-wiznet MACRAW driver
        +
embassy-net software TCP/IP stack

It is not classified as:

W5500 hardware socket API
or
direct W5500 TCP/UDP socket-register control

The W5500 is effectively used as an SPI-connected Ethernet MAC/PHY and raw-frame interface. This design allows the same KNX/IP socket abstractions to be used with W5500 Ethernet, Pico W Wi-Fi, and Linux networking, but it does not use the W5500’s main hardware-offload advantage.

Hybrid Network Assessment

Hybrid Network: No

The repository contains both Ethernet and Wi-Fi implementations, but they are built as separate firmware targets:

pico_eth_light_switch   → W5500 Ethernet
pico_wifi_light_switch  → CYW43439 Wi-Fi

The Wi-Fi firmware initializes the Pico W’s CYW43439 interface and builds its KNX/IP link layer on wlan0, while the Ethernet firmware builds the equivalent interface on eth0. No examined firmware target concurrently operates W5500 Ethernet and Wi-Fi as a unified network system.

The KNX/IP interface combines W5500 Ethernet with a wired KNX TP1 bus. This is a multi-medium gateway between Ethernet and a fieldbus, but it is not a wired-and-wireless Hybrid Network under the stated classification criteria.

Operation Flow

W5500 KNX/IP Light Switch

1. Read serial number and MAC address from flash
2. Initialize RP2040 SPI0 and W5500
3. Start the W5500 background driver task
4. Load the ETS-downloaded network configuration
5. Select DHCP or stored static IPv4 configuration
6. Start embassy-net
7. Allocate KNX/IP UDP socket resources
8. Create the KNXnet/IP link-layer builder
9. Start the compile-time-composed KNX System B stack
10. Wait for the ETS application to enter the running state
11. Convert physical button events into KNX communication-object events
12. Transmit routing, discovery, control, or management messages over KNX/IP
13. Persist configuration changes and device state in flash

The standard Ethernet light-switch target uses a routing-oriented UDP configuration with separate sockets for KNX/IP discovery, control, and routing. Its application task waits until ETS has loaded and started the device application before processing physical button events.

KNX/IP-to-TP1 Interface

KNX/IP Client or ETS
        │
        ▼
Ethernet / W5500
        │
        ▼
embassy-net UDP and TCP sockets
        │
        ▼
KNXnet/IP Discovery, Management and Tunneling
        │
        ▼
IpInterfaceLinkLayerBuilder
        │
        ├──────── KNX/IP Side
        │
        └──────── TP-UART Side
                         │
                         ▼
                    NCN5120
                         │
                         ▼
                     KNX TP1 Bus

The interface firmware uses W5500 Ethernet on SPI0 and an NCN5120 TP-UART transceiver on UART0. UART0 is configured for 19,200 baud with even parity. A composite link-layer builder presents both media to the upper KNX stack as one logical link layer.

This firmware supports the architecture required for ETS discovery, device management, tunneling connections, and the forwarding of KNX telegrams between an IP network and a TP1 segment. The repository classifies the IP-interface link layer as implemented but not yet rigorously tested.

Technical Characteristics

Compile-Time Composition

Protocol layers, services, storage, extensions, and media are selected as Rust types. Unused features are intended to produce no runtime registry or hot-path dynamic dispatch. This approach improves determinism and reduces unnecessary embedded code, although it increases generic-type complexity and compile-time coupling.

Persistent Storage

The project provides flash and FRAM-oriented storage layouts, wear-levelled key-value storage, sequence-number persistence, and JSON backends for Linux hosts. Secure firmware maintains replay-protection counters and an IP Secure multicast-timer watermark in dedicated persistent regions.

ETS Integration

Device parameters, communication objects, and ETS user-interface pages are declared through Rust macros. The generator produces MTXML and .knxprod files from the same device definitions used by the firmware, reducing duplication between device code and ETS product data. Generated .knxprod packages require an external converter private key that is intentionally not distributed in the repository.

Strengths

1. Unified Rust implementation across MCU and Linux targets
   The same protocol core is designed for allocation-free embedded firmware and Linux-based development or testing.
2. Concrete W5500 and RP2040 reference firmware
   The repository includes executable KNX/IP device and gateway targets rather than limiting the project to abstract protocol definitions.
3. Broad KNX scope
   TP1, RF, KNX/IP, secure communication, ETS product generation, provisioning, storage, and conformance tooling are maintained within one workspace.
4. Async embedded architecture
   Embassy tasks separate the W5500 driver, software network stack, KNX router, application processing, and persistent-storage operations.
5. Reproducible device and product definitions
   Firmware configuration and ETS product metadata originate from Rust definitions, reducing the risk of manually maintained firmware and ETS descriptions diverging.
6. Security-oriented storage design
   Data Secure sequence counters and IP Secure timer state are treated as durable security state rather than ordinary volatile runtime variables.

Limitations

1. No official KNX certification
   “Conformance-tested” refers to the repository author’s implementation of published tests. It is not an official certification claim.
2. Several features require further validation
   KNX/IP tunneling, IP Secure, KNX-RF transmission, USB HID, and the IP-to-TP1 composite interface are listed as implemented but not rigorously tested.
3. Power-loss risk during configuration updates
   The current configuration persistence process uses a single-copy erase-and-write procedure. A power interruption during this window may erase the ETS configuration.
4. Limited Data Point Type coverage
   The repository reports support for approximately two dozen DPTs required by its demonstration devices rather than the complete KNX DPT catalogue.
5. No line-coupler or router implementation
   KNX line couplers, filter tables, and KNX/IP backbone-router functions are not implemented.
6. System B only
   Other KNX device profiles and mask families are not currently implemented.
7. TOE capability is unused
   MACRAW mode improves network-stack portability but leaves W5500 hardware TCP/UDP offload unavailable. The RP2040 must execute the software TCP/IP stack.
8. Licensing and certification constraints
   The project is available under AGPL-3.0 or a separate commercial license. Shipping an officially certified KNX product still requires the appropriate KNX Association process and product-level testing.

Application Value

The project has strong reference value for:

• Rust-based KNX sensor, actuator, switch, and control-panel development
• W5500-connected KNX/IP devices
• KNX/IP-to-TP1 interface products
• Secure building-automation endpoints
• Common protocol cores shared between Linux simulation and MCU firmware
• Compile-time generation of device stacks and ETS product definitions
• Async Rust networking on RP2040-class microcontrollers
• Evaluation of MACRAW-based W5500 integration with a portable software TCP/IP stack

From a WIZnet perspective, the most significant implementation is the RP2040 KNX/IP firmware family. It demonstrates W5500 Ethernet integration within an async Rust ecosystem and applies the device to KNX discovery, routing, management, secure communication, and IP-to-TP1 bridging.

The implementation is not a TOE reference because the hardware socket engine is bypassed. Its primary value is instead the portability of a single software networking architecture across W5500 Ethernet, Wi-Fi, and Linux targets.

Author Information

The repository is published by the Netrunner UG GitHub organization. The organization identifies zweidraehte as its primary public Rust project and provides development and consulting services for KNX firmware, hardware porting, ETS product definitions, .knxprod tooling, and KNX security work.

Final Assessment

zweidraehte is a technically ambitious Rust implementation covering the KNX device runtime, multiple physical media, secure services, product-data generation, persistent storage, and conformance-oriented testing.

Its W5500 implementation is concrete and well separated into driver, software network stack, KNX/IP transport, and application layers. The W5500 is used in MACRAW mode through embassy-net-wiznet, so TOE is not used. Ethernet and Wi-Fi are provided as separate firmware targets, so the project is not classified as a Hybrid Network.

The repository provides substantial value as an experimental KNX platform and Rust embedded-networking reference. Product deployment remains subject to further hardware validation, power-failure-safe persistence improvements, broader protocol coverage, and official KNX certification.

zweidraehte: W5500 기반 KNX/IP 펌웨어를 포함한 Rust KNX 디바이스 스택

프로젝트 개요

zweidraehte는 Rust로 구현된 KNX 디바이스 측 프로토콜 스택이다. 동적 메모리 할당이 없는 no_std 코어를 중심으로 구성되며, 동일한 핵심 구현을 베어메탈 마이크로컨트롤러와 임베디드 Linux 환경에서 사용할 수 있도록 설계됐다.

장치가 사용하는 통신 매체, 프로토콜 확장, 인터페이스 객체, 저장장치, 보안 기능은 런타임 등록 방식이 아니라 Rust 타입과 trait를 이용해 컴파일 시점에 조합된다. 사용하지 않는 기능이 런타임 레지스트리나 동적 디스패치 경로에 남지 않도록 한 구조다.

프로젝트 범위는 KNX 통신 스택에 한정되지 않는다.

• KNX TP1
• KNX-RF
• KNXnet/IP
• USB HID
• KNX/IP와 TP1을 연결하는 복합 링크 계층
• KNX Data Secure
• KNX IP Secure
• ETS 파라미터 및 통신 객체 정의용 Rust DSL
• MTXML 및 .knxprod 생성기
• 장치 프로비저닝 도구
• 자체 적합성 시험 프레임워크
• STM32G0, RP2040, Pico W 및 Linux용 참조 펌웨어

이 기능들이 하나의 Rust workspace에 포함돼 있다.

저장소는 현재 상태를 작업 진행 중인 구현으로 명시한다. 자체 적합성 시험은 공개된 KNX 시험 사양의 상당 부분을 실행하지만, KNX Association의 공식 인증이나 공식 EITT 환경을 통한 검증 결과는 아니다.

프로젝트 유형

KNX의 네트워크 계층, 전송 계층, 애플리케이션 계층은 동기식 처리 구조를 사용하며, 하나의 비동기 라우터 루프가 계층 간 메시지를 구동한다. 실제 통신 매체는 Embassy 또는 Linux executor 위의 개별 비동기 태스크로 실행된다.

동작 흐름

W5500 KNX/IP 조명 스위치

1. Flash에서 시리얼 번호와 MAC 주소 로드
2. RP2040 SPI0 및 W5500 초기화
3. W5500 비동기 드라이버 태스크 실행
4. ETS에서 다운로드된 네트워크 설정 확인
5. DHCP 또는 저장된 정적 IPv4 방식 선택
6. embassy-net 실행
7. KNX/IP UDP 소켓 풀 생성
8. KNXnet/IP 링크 계층 생성
9. KNX System B 스택 실행
10. ETS 애플리케이션이 실행 상태가 될 때까지 대기
11. 물리 버튼 입력을 KNX 통신 객체 이벤트로 변환
12. KNX/IP discovery, control, routing 메시지 송수신
13. 변경된 설정과 상태를 Flash에 저장

표준 Ethernet 조명 스위치는 discovery, control, routing을 위한 UDP 소켓을 구성한다. 애플리케이션 태스크는 ETS가 장치 애플리케이션을 다운로드하고 실행 상태로 전환한 이후 물리 버튼 입력을 처리한다.

KNX/IP-to-TP1 인터페이스

ETS 또는 KNX/IP 클라이언트
        │
        ▼
Ethernet / W5500
        │
        ▼
embassy-net UDP·TCP
        │
        ▼
KNXnet/IP Discovery·Management·Tunneling
        │
        ▼
IpInterfaceLinkLayerBuilder
        │
        ├──────── KNX/IP 링크
        │
        └──────── TP-UART 링크
                         │
                         ▼
                    NCN5120
                         │
                         ▼
                     KNX TP1

해당 펌웨어는 SPI0에 연결된 W5500과 UART0에 연결된 NCN5120 TP-UART 트랜시버를 함께 사용한다. UART0는 19,200 baud, even parity로 구성된다.

IpInterfaceLinkLayerBuilder는 KNX/IP 링크와 TP-UART 링크를 하나의 복합 링크 계층으로 묶는다. 상위 KNX 스택은 이를 하나의 논리적인 통신 매체로 사용한다.

이 구조는 Ethernet 측 KNX/IP 터널링 연결과 TP1 버스 사이의 KNX 텔레그램 전달에 사용된다. 다만 저장소 상태표에는 해당 복합 링크 계층이 아직 충분히 시험되지 않은 것으로 기록돼 있다.

시스템 구조

장치 정의 및 ETS DSL
        │
        ├── 파라미터
        ├── 통신 객체
        ├── ETS 설정 화면
        └── 인터페이스 객체
        │
        ▼
컴파일 시점 Rust 조합
        │
        ├── System B BCU 프로파일
        ├── 보안 확장
        ├── 저장장치
        ├── 애플리케이션 서비스
        └── 통신 매체
        │
        ▼
KNX 디바이스 스택
        │
        ├── Application Layer
        ├── Transport Layer
        ├── Network Layer
        └── Async Message Router
        │
        ▼
링크 계층
        │
        ├── KNX TP1 / TP-UART
        ├── KNX-RF
        ├── KNXnet/IP
        ├── USB HID
        └── KNX/IP ↔ TP1 복합 인터페이스
        │
        ▼
실제 하드웨어 또는 Linux 네트워크

주요 소프트웨어 구성요소

저장소는 프로토콜 정의, 디바이스 스택, procedural macro, ETS 도구, 제품 패키지 생성기, 플랫폼 코드, 시험 프레임워크와 펌웨어를 명확히 분리한다.

참조 하드웨어 및 펌웨어

STM32G0

STM32G0 계열에는 TP1 조명 스위치, Data Secure 스위치, KNX-RF 장치와 RF 재전송기 펌웨어가 포함된다. TP1 통신은 TP-UART 2, NCN5120, E981.03과 같은 TP-UART 계열 트랜시버를 대상으로 한다.

RP2040

RP2040 하위에는 다음 펌웨어가 독립된 프로젝트로 구성된다.

• W5500 Ethernet KNX/IP 조명 스위치
• W5500 Ethernet KNX IP Secure 조명 스위치
• W5500 Ethernet-to-TP1 KNX/IP 인터페이스
• Pico W Wi-Fi KNX/IP 조명 스위치
• RP2040 TP1 조명 스위치

Ethernet과 Wi-Fi는 하나의 장치에서 동시에 구동되는 인터페이스가 아니라 서로 다른 펌웨어 타깃이다.

WIZnet 제품 사용 여부

WIZnet Product Role: W5500 사용 확인

사용 제품: WIZnet W5500 Ethernet Controller

W5500은 RP2040 기반 KNX/IP 펌웨어의 Ethernet 인터페이스로 사용된다. W5500 사용이 확인되는 주요 타깃은 Ethernet 조명 스위치, Ethernet 보안 조명 스위치, KNX/IP-to-TP1 인터페이스다.

RP2040 Ethernet 조명 스위치 코드에 정의된 연결은 다음과 같다.

SPI0는 50 MHz로 설정된다. embassy-net-wiznet이 W5500을 초기화하고, 별도의 Embassy 태스크가 W5500 드라이버의 비동기 실행 루프를 담당한다.

W5500 통신 계층

RP2040 애플리케이션
        │
        ▼
zweidraehte KNXnet/IP 링크 계층
        │
        ▼
UDP/TCP 소켓 추상화
        │
        ▼
embassy-net 소프트웨어 네트워크 스택
        │
        ▼
embassy-net-wiznet
        │
        ▼
W5500 MACRAW 인터페이스
        │
        ▼
Ethernet

W5500 초기화 이후 embassy-net이 DHCP 또는 저장된 정적 IPv4 설정을 처리한다. KNX/IP 계층은 embassy-net 위에 생성된 UDP 및 TCP 소켓 풀을 사용한다.

TOE 사용 여부

TOE 사용 여부: 사용하지 않음

이 프로젝트는 W5500의 하드웨어 TCP/IP 소켓 엔진을 일반적인 TCP/IP Offload Engine 방식으로 사용하지 않는다.

embassy-net-wiznet은 W5500을 MACRAW 모드로 동작시키는 드라이버다. W5500은 Ethernet 프레임 송수신을 담당하고, IPv4, DHCP, UDP, TCP, 멀티캐스트와 소켓 관리는 RP2040에서 실행되는 embassy-net 소프트웨어 스택이 처리한다.

따라서 네트워크 경로는 다음으로 분류된다.

embassy-net-wiznet MACRAW 드라이버
        +
embassy-net 소프트웨어 TCP/IP 스택

다음 구조에는 해당하지 않는다.

W5500 하드웨어 소켓 API 사용
또는
W5500 TCP/UDP 소켓 레지스터 직접 제어

W5500은 SPI 기반 Ethernet MAC/PHY 및 Raw Ethernet 프레임 인터페이스에 가까운 역할을 수행한다.

이 구조는 W5500 Ethernet, Pico W Wi-Fi, Linux 환경에서 동일한 KNX/IP 소켓 추상화를 재사용하기에 유리하다. 반면 W5500이 제공하는 하드웨어 TCP/IP 처리 이점은 활용하지 못한다.

Hybrid Network 여부

Hybrid Network: 해당하지 않음

저장소에는 Ethernet과 Wi-Fi 펌웨어가 모두 존재하지만, 각 네트워크 방식은 별도의 바이너리로 구현된다.

pico_eth_light_switch   → W5500 Ethernet
pico_wifi_light_switch  → CYW43439 Wi-Fi

Wi-Fi 펌웨어는 Pico W의 CYW43439를 초기화하고 wlan0 기반 KNX/IP 링크 계층을 생성한다. Ethernet 펌웨어는 W5500과 eth0 기반 링크 계층을 사용한다. 확인한 펌웨어에는 W5500 Ethernet과 Wi-Fi를 동시에 구동하는 통합 네트워크 구성이 없다.

KNX/IP 인터페이스는 W5500 Ethernet과 유선 KNX TP1 버스를 연결한다. 서로 다른 유선 통신 매체를 연결하는 게이트웨이지만, 유선과 무선 네트워크를 함께 사용하는 Hybrid Network에는 해당하지 않는다.

기술적 특징

컴파일 시점 조합

프로토콜 계층, 통신 매체, 저장장치와 확장 기능이 Rust 타입으로 조합된다. 사용하지 않는 기능을 런타임 등록 테이블에서 제거하고, 실행 경로의 동적 디스패치를 줄이는 구조다. 임베디드 환경에서 예측 가능한 실행과 코드 크기 절감에 유리하지만, generic 타입과 trait 관계가 복잡해질 수 있다.

영구 저장장치

Flash와 FRAM을 위한 영역 기반 저장 구조, wear-levelled key-value 저장소, 보안 시퀀스 번호 저장과 Linux용 JSON backend가 구현돼 있다.

보안 펌웨어는 재전송 공격 방지에 필요한 카운터와 KNX IP Secure 멀티캐스트 타이머 watermark를 별도의 영구 영역에 저장한다.

ETS 연동

장치 파라미터, 통신 객체와 ETS 설정 화면을 Rust 매크로로 정의한다. 동일한 정의에서 펌웨어 구조와 MTXML·.knxprod 제품 데이터를 생성하므로, 펌웨어와 ETS 제품 정의가 서로 달라지는 문제를 줄일 수 있다.

서명된 .knxprod 생성에는 저장소에 포함되지 않은 외부 converter private key가 필요하다.

장점

1. MCU와 Linux에서 공유되는 Rust 코어
   베어메탈 장치와 Linux 시험 환경에서 동일한 KNX 핵심 구현을 사용할 수 있다.
2. 구체적인 W5500 참조 펌웨어
   추상적인 프로토콜 라이브러리에 그치지 않고 RP2040과 W5500을 이용한 조명 스위치 및 KNX/IP 인터페이스가 포함된다.
3. 넓은 KNX 구현 범위
   TP1, RF, KNX/IP, 보안, ETS 제품 생성, 프로비저닝, 저장장치와 시험 도구를 하나의 프로젝트에서 제공한다.
4. 비동기 임베디드 구조
   W5500 드라이버, 소프트웨어 네트워크 스택, KNX 라우터, 애플리케이션과 저장 태스크가 Embassy 기반으로 분리된다.
5. 펌웨어와 ETS 제품 정의의 통합
   Rust 장치 정의에서 펌웨어 구조와 ETS 제품 데이터를 함께 생성한다.
6. 보안 상태의 영구 저장
   Data Secure 및 IP Secure에 필요한 상태를 일반 런타임 변수와 분리해 Flash에 보존한다.

한계

1. 공식 KNX 인증 미확보
   자체 적합성 시험 결과는 공식 KNX 인증을 의미하지 않는다.
2. 추가 시험이 필요한 기능 존재
   KNX/IP tunneling, IP Secure, KNX-RF 송신, USB HID와 KNX/IP-to-TP1 인터페이스는 구현됐지만 충분한 검증이 완료되지 않았다.
3. 설정 저장 중 전원 차단 위험
   ETS 설정은 단일 사본을 지우고 다시 기록하는 방식이다. 저장 시점에 전원이 차단되면 설정을 잃을 수 있다.
4. 제한적인 DPT 지원
   데모 장치에 필요한 약 20여 개 Data Point Type이 구현돼 있으며, 전체 KNX DPT 카탈로그를 지원하지 않는다.
5. Line Coupler와 Router 미구현
   필터 테이블을 포함한 KNX line coupler와 KNX/IP backbone router는 지원하지 않는다.
6. System B 프로파일 한정
   현재 다른 KNX 디바이스 프로파일과 mask 계열은 구현되지 않았다.
7. W5500 TOE 미사용
   MACRAW 방식이므로 TCP/IP 처리 부하는 RP2040의 소프트웨어 스택이 담당한다.
8. 라이선스와 제품 인증 조건
   AGPL-3.0 또는 별도 상용 라이선스를 사용한다. 실제 KNX 인증 제품 출시는 별도의 KNX Association 절차와 제품 시험이 필요하다.

적용 가치

이 프로젝트는 다음 분야에서 참조 가치가 있다.

• Rust 기반 KNX 센서 및 액추에이터 개발
• W5500을 이용한 KNX/IP 디바이스
• Ethernet-to-TP1 KNX 인터페이스
• KNX Data Secure 및 IP Secure 장치
• Linux 시뮬레이션과 MCU 펌웨어가 공유하는 프로토콜 코어
• ETS 제품 데이터 자동 생성
• RP2040 기반 async Rust 네트워크
• W5500 MACRAW와 소프트웨어 TCP/IP 스택의 결합 사례

WIZnet 관점의 핵심은 RP2040 KNX/IP 펌웨어다. W5500을 Rust async 환경에 연결하고, 이를 KNX/IP discovery, routing, management, 보안 통신과 TP1 브리지에 적용한다.

W5500 하드웨어 소켓을 이용하는 TOE 사례는 아니지만, W5500 Ethernet, Pico W Wi-Fi와 Linux가 동일한 KNX/IP 추상화 계층을 공유한다는 점에서 네트워크 이식성 중심의 구현 사례가 된다.

저자 정보

저장소는 Netrunner UG GitHub 조직에서 공개했다. 해당 조직은 zweidraehte를 주요 Rust 프로젝트로 관리하며, KNX 펌웨어 개발, 대상 하드웨어 포팅, ETS 제품 정의, .knxprod 도구와 KNX 보안 관련 개발 및 컨설팅을 제공한다고 명시한다.