Wiznet makers

프로젝트가 실제로 하는 일

이 레포는 K1921VG015용 CANopenNode 포팅에 더해, **W5500 모듈(SPI)**을 사용해 “CANopen 로그를 웹 서버로 제공”하는 구성을 목표로 합니다. 즉, 설비 현장에서 CANopen 노드의 상태를 PC에 직접 붙지 않고도 같은 이더넷망에서 브라우저/스크립트로 확인할 수 있는 진단 게이트웨이 베이스라인입니다.

이미지 출처 : https://github.com/x893/CANopenNode-VG015

CANopenNode

CANopen은 산업용 현장에서 널리 쓰이는 CAN 버스 기반 상위 통신 프로토콜로, 장치의 파라미터를 표준화된 **오브젝트 딕셔너리(OD)**로 표현하고 SDO/PDO, NMT(네트워크 관리), 하트비트/가드 같은 메커니즘으로 제어·상태교환을 합니다.
CANopenNode는 이런 CANopen 기능을 임베디드 장치에 올리기 위한 C 기반 CANopen 스택이며, 스택 코어는 하드웨어 독립적으로 구성되고 실제 제품/보드에서는 MCU에 맞춘 CAN 드라이버·타이머·저장(Flash) 등 타깃 레이어를 붙여 포팅합니다.

이미지 출처 : https://github.com/CANopenNode/CANopenNode

K1921VG015

K1921VG015는 NIIET의 RISC-V 기반 32비트 MCU로 소개되며, 내부 NVM, 멀티채널 ADC, 암호 코프로세서, 직렬 인터페이스, 접근 보호 기능 등을 갖추고 최대 50MHz 동작이 언급됩니다. 이 프로젝트에서는 CANopenNode가 구동되는 타깃 MCU 역할을 합니다.

이미지 출처 : https://www.chipdip.ru/

niiet_riscv_sdk

niiet_riscv_sdk는 NIIET RISC-V MCU용 개발 SDK(툴체인/프로젝트 템플릿/스타트업·링커/기본 드라이버) 성격의 묶음으로, K1921VG015에서 펌웨어를 빌드·플래시·디버그하기 위한 기반 환경을 제공합니다. 이 레포도 해당 SDK 기반의 개발 흐름을 전제합니다.

이미지 출처 : https://syntacore.com/

WIZnet W5500이 게이트웨이에 들어가는 기술적 이유

이 프로젝트의 네트워크 경로는 “MCU 소프트 TCP/IP 스택” 대신, W5500의 하드웨어 TCP/IP + SPI 인터페이스를 활용하는 방향과 잘 맞습니다. W5500은 하드웨어 소켓(최대 8개), 내부 버퍼(32KB), SPI 최대 80MHz 등이 문서/제품 설명에 명시돼 있어, MCU가 CANopen 주기 처리에 집중하면서도 유선 이더넷 진단 채널을 구성하기에 현실적인 선택지입니다.

이미지 출처 : https://github.com/x893/CANopenNode-VG015

코드 기반 기술 분석: “CANopen 메인 루프 + HTTP 폴링” 결합 방식

1) W5500 드라이버 활성화와 정적 IP 설정

레포는 Mongoose 설정에서 W5500 드라이버를 활성화하고, 정적 IP(예: 192.168.1.20/24) 형태를 예시로 둡니다. 이는 DHCP에 의존하지 않고 설비 주소 체계를 고정해야 하는 산업 환경에서 자주 쓰는 운영 방식입니다.

2) W5500을 “실제 네트워크 인터페이스”로 선택하는 구조

이 프로젝트는 Mongoose가 제공하는 W5500 드라이버를 통해 W5500을 네트워크 인터페이스처럼 다루는 형태를 취합니다. 즉, 애플리케이션은 HTTP 처리와 CANopen 로직에 집중하고, “이더넷 링크/소켓 처리”는 W5500+드라이버 조합이 담당하는 구조로 정리됩니다. (레포 소개 자체가 W5500 기반 웹 서버를 명시합니다.)

3) HTTP API 골격: /api 기반 진단·명령 주입의 출발점

README 수준에서 “CANopen 로그용 웹 서버”가 목표로 명확히 제시돼 있으므로, 산업용 IoT 관점에서는 다음 확장이 자연스럽습니다:

상태/로그 조회: 최근 이벤트를 링버퍼로 저장 후 API로 제공

제어/테스트: 허용된 범위 내에서만 명령 주입(화이트리스트/ACL 필수)

운영 보호: 인증/레이트리밋/감사 로그
이렇게 하면 “현장 디버그 편의”와 “운영 안전성”을 동시에 챙길 수 있습니다.

FAQ

1) 왜 이 프로젝트에서 W5500 기반 유선 이더넷이 산업용 IoT에 유리한가요?

산업 현장에서는 무선처럼 환경에 따라 품질이 흔들리는 연결보다, 장애 분석이 쉬운 유선 연결이 선호됩니다. W5500은 하드웨어 TCP/IP 기반으로 임베디드에서 네트워크 구현을 단순화할 수 있고, 8 소켓과 32KB 버퍼 같은 특성으로 진단 트래픽(웹, API)과 장치 업무 트래픽을 분리 설계하기에도 유용합니다.

2) CANopenNode는 왜 “포팅 구조”가 중요하고, 이 프로젝트는 무엇을 보여주나요?

CANopenNode는 스택 코어가 “하드웨어 독립”으로 설계돼 있어, 실제 제품에서는 타깃 MCU에 맞춘 CAN 드라이버/타이머/저장 계층을 반드시 붙여야 합니다. CANopenNode-VG015는 그런 포팅의 전형적인 형태(타깃 MCU에서 스택을 돌리고, 주변 기능을 결합)를 보여주며, 여기에 W5500 기반 HTTP 진단 채널을 추가해 산업용 운용에 가까운 방향으로 확장합니다.

3) niiet_riscv_sdk는 개발에서 왜 중요하죠?

이 레포는 단순 소스 모음이 아니라, K1921VG015에서 바로 올릴 수 있는 개발 흐름을 전제합니다. niiet_riscv_sdk는 툴체인/프로젝트 기반/기본 드라이버를 제공하는 성격이어서, SDK 버전이나 프로젝트 골격이 맞지 않으면 빌드·링크·디버그 단계에서 재현이 어려워질 수 있습니다. 따라서 “레포 + SDK”를 한 세트로 보는 것이 현실적입니다.

4) 지금 상태에서 “진짜 게이트웨이”로 완성하려면 무엇을 더 해야 하나요?

게이트웨이로 완성하려면, CANopen 상태/이벤트를 안정적으로 축적하는 버퍼(링버퍼 + 타임스탬프), 외부에서 호출할 API의 범위(읽기 중심 → 제한된 쓰기), 그리고 운영 보호(인증/레이트리밋/권한 분리)가 필요합니다. 특히 “원격 명령 주입”은 디버깅에는 유용하지만 운영 환경에서는 오남용 위험이 크므로, W5500로 접근 가능한 HTTP API에 반드시 제약 조건을 두는 것이 좋습니다.

5) W5500 대신 다른 방식(LwIP, Linux SocketCAN 등)을 쓰면 더 나은가요?

LwIP 기반 MCU 이더넷은 유연하지만 RAM/튜닝/타이밍 관리 부담이 커질 수 있고, Linux(SocketCAN) 게이트웨이는 개발은 빠르지만 BOM/전력/부팅/내환경 요구가 까다로워질 수 있습니다. 이 레포의 “단일 MCU + W5500 + HTTP 진단” 구조는 작고 단순하며, 유선 이더넷 기반의 유지보수성을 우선하는 산업용 IoT 요구에 잘 맞습니다.

What the project actually does

This repository ports CANopenNode to the K1921VG015 MCU and aims to provide “CANopen logs via a web server” using a WIZnet W5500 (SPI) module. In other words, it’s a diagnostic gateway baseline that lets you check a CANopen node’s status from a browser or script over the same Ethernet network—without plugging a PC directly into the device on the shop floor.

Image source: https://github.com/x893/CANopenNode-VG015

CANopenNode

CANopen is a widely used higher-layer protocol on top of the CAN bus in industrial environments. It represents device parameters through a standardized Object Dictionary (OD) and uses mechanisms such as SDO/PDO, NMT (Network Management), and heartbeat/guarding for control and state exchange.
CANopenNode is a C-based CANopen stack designed for embedded systems. Its core is hardware-agnostic, so real products typically “port” it by adding target-specific layers such as the MCU’s CAN driver, timers, and non-volatile storage (Flash).

Image source: https://github.com/CANopenNode/CANopenNode

K1921VG015

The K1921VG015 is introduced as a 32-bit RISC-V MCU from NIIET. It is described as including internal NVM, a multi-channel ADC, a crypto coprocessor, serial interfaces, and access-protection features, with a mentioned maximum operating frequency of 50 MHz. In this project, it serves as the target MCU running CANopenNode.

MCU Features (K1921VG015)

MCU Feature (K1921VG015)	Spec / Point
32-bit RISC-V MCU	32-bit RISC-V microcontroller
Max clock	50 MHz
Program Flash	1 MB (Flash)
RAM	256 Kb + 64 Kb
Interfaces	CAN 2.0b, USB 2.0 FS, I2C, QSPI, SPI
Supply / temperature	1.6–3.6 V, -40 to +85°C
Approx. price	~610 RUB to ~2,180 RUB
Price in USD (approx.)	~7.92 USD to ~28.32 USD
Part name (RU listing)	“Микросхема интегральная К1921ВГ015”

Image source: https://www.chipdip.ru/

niiet_riscv_sdk

niiet_riscv_sdk is a development SDK bundle for NIIET RISC-V MCUs. It typically includes the toolchain setup, project templates, startup and linker scripts, and baseline drivers needed to build, flash, and debug firmware on targets like the K1921VG015. This repository assumes a development flow based on that SDK.

Image source: https://syntacore.com/

Why WIZnet W5500 makes technical sense for this gateway

This project’s networking approach aligns well with using the W5500’s hardware TCP/IP offload over SPI, instead of running a full software TCP/IP stack on the MCU. The W5500’s documented capabilities—such as up to 8 hardware sockets, a 32KB internal buffer, and SPI up to 80 MHz—make it a practical choice when you want the MCU to stay focused on CANopen’s cyclic timing while still providing a stable, wired Ethernet diagnostics channel.

Image source: https://github.com/x893/CANopenNode-VG015

Code-based technical analysis: “CANopen main loop + HTTP polling” integration

1) Enabling the W5500 driver and using a static IP

In the Mongoose configuration, the repository enables the W5500 driver and shows an example of a static IP configuration (e.g., 192.168.1.20/24). This is common in industrial environments where devices must keep fixed addresses and should not depend on DHCP.

2) Treating W5500 as the “real network interface”

The project uses the W5500 driver provided by Mongoose so that the W5500 behaves like the system’s network interface. The application can focus on HTTP processing and CANopen logic, while the “Ethernet link/socket handling” is managed by the W5500 + driver combination. (The repo description itself explicitly calls out a W5500-based web server.)

3) HTTP API skeleton: a starting point for diagnostics and command injection

Because the README clearly states the goal of a “web server for CANopen logs,” the natural Industrial IoT extensions look like this:

Status/log readout: store recent events in a ring buffer and expose them via an API

Control/testing: allow command injection only within approved limits (whitelist/ACL required)

Operational protection: authentication, rate limiting, and audit logging

This gives you both “on-site debugging convenience” and “operational safety.”

FAQ

1) Why is W5500-based wired Ethernet beneficial for Industrial IoT in this project?

In industrial sites, wired connectivity is often preferred over wireless because failures are easier to analyze and the link quality is less sensitive to environmental conditions. Since the W5500 provides hardware TCP/IP, it can simplify embedded networking. Its 8 sockets and 32KB buffer also help you separate diagnostic traffic (web/API) from device workload traffic in a cleaner, more controlled way.

2) Why does CANopenNode’s “porting structure” matter, and what does this project show?

CANopenNode’s core stack is designed to be hardware-independent, so real products must attach target-specific layers like a CAN driver, timers, and storage. CANopenNode-VG015 demonstrates that typical porting pattern (running the stack on a target MCU and integrating board-level functionality) and extends it by adding an HTTP diagnostics channel via W5500, pushing it closer to an industrial operating model.

3) Why is niiet_riscv_sdk important for development?

This repository is not just a loose collection of source files—it assumes a build and debug flow that works directly on the K1921VG015. Since niiet_riscv_sdk provides toolchain integration, project scaffolding, and baseline drivers, mismatches in SDK version or project structure can make the build/link/debug steps hard to reproduce. Practically, you treat “repo + SDK” as one package.

4) What do you still need to turn this into a “real gateway”?

To complete the gateway, you typically need a robust buffer for CANopen status/events (ring buffer + timestamps), a clear definition of what the API is allowed to do (read-first, limited writes), and operational safeguards (authentication, rate limiting, privilege separation). “Remote command injection” is especially risky in production, so HTTP endpoints reachable via W5500 should be constrained by strict allowlists and policy checks.

5) Would other approaches (LwIP, Linux SocketCAN, etc.) be better than W5500?

LwIP-based MCU Ethernet can be flexible, but it can also increase RAM usage and tuning/timing complexity. A Linux(SocketCAN) gateway can speed development, but it raises BOM, power, boot time, and environmental requirements. This repo’s “single MCU + W5500 + HTTP diagnostics” approach stays small and straightforward, and it fits Industrial IoT needs that prioritize maintainability and wired-network stability.