Wiznet makers

이 펌웨어는 원격에서 모터를 제어하기 위한 펌웨어이며, “상위 제어기(PC) → 네트워크 명령 → 임베디드 실시간 구동” 구조를 구현합니다.
네트워크 인터페이스는 W5100/W5500 기반 Ethernet이며, 제어 프로토콜은 OSC(Open Sound Control) 입니다.
또한 STEP400/STEP800, STEP100/200처럼 하드웨어 구성이나 세부 기능이 다른 여러 제품을 각각 따로 만들지 않고, 하나의 공통 코드(단일 코드베이스)로 모두 지원하도록 정리되어 있습니다.

OSC(Open Sound Control)란?

OSC는 원래 음악/미디어/인터랙티브 아트 분야에서 널리 쓰이던 실시간 제어용 메시지 포맷/프로토콜입니다. 보통 UDP 위에서 동작하며, 다음 특징을 가집니다.

주소 기반(Address Pattern): 예) /motor/1/pos, /axis/0/vel 처럼 “경로” 형태로 명령을 구분

타입 태그 + 바이너리 페이로드: int/float/string 등 타입이 명확해 파싱/확장이 쉬움

Bundle(번들) 지원: 여러 메시지를 하나로 묶고, **타임태그(시간 정보)**를 포함 가능

에코시스템 풍부: PC/툴(예: TouchDesigner, Max, Processing, Python 등)에서 쉽게 송수신 가능

즉, OSC는 “실시간으로 여러 제어 파라미터를 빠르게 흘려보내고, 확장 가능한 형태로 유지”하기 좋은 규격입니다.

핵심 목표

핵심은 **“네트워크 스택 부담을 MCU에서 덜어 모션 루프에 시간/메모리를 남기는 것”**입니다.
W5500는 Hardwired TCP/IP를 제공하고(소프트 스택 대비 CPU/RAM 부담 감소), 내부 버퍼(32KB)와 다중 소켓(8개)을 갖춰 UDP 기반 명령/상태 흐름을 구성하는 데 적합합니다.

또한 보드별로 W5500 CS 핀을 설정 가능하게 하는 등, 비표준 구성에도 대응합니다.

Architecture (OSC → 모션 → 드라이버)

흐름

PC/상위 제어기 → UDP로 OSC 메시지 전송

W5100/W5500 → UDP 페이로드 수신/버퍼링

SAMD MCU → OSC 파싱 → 축별 목표값(위치/속도/가속도) 갱신

L6470/PowerSTEP01 → 모터 구동

설계 포인트

OSC 수신 루프가 모션 제어 타이밍을 방해하지 않도록, 네트워크 처리는 “짧게 읽고 큐잉”하는 방식 
(Internet Offload 유리)

이미지 출처 : AI 생성

FAQ (3)

1) 왜 W5500를 쓰나요?

유선 Ethernet에서 UDP/OSC를 안정적으로 처리하면서 MCU는 모션 계산과 드라이버 제어에 집중해야 합니다. W5500는 하드웨어 TCP/IP, 32KB 버퍼, 8 소켓을 제공해 소프트 스택 대비 MCU 부담을 줄이는 방향의 설계가 가능합니다.

2) 로봇에서 OSC(UDP)는 어떤 장점이 있나요?

OSC는 실시간 제어에서 “빠르게 명령을 흘려보내는” 패턴과 잘 맞습니다. UDP는 재전송/연결 유지 비용이 적어 지연이 짧을 수 있지만, 손실 가능성이 있어 애플리케이션 레벨에서 안전장치(시퀀스/타임아웃)가 필요할 수 있습니다.

3) LwIP 같은 소프트웨어 스택 대비 어떤 차이가 있나요?

LwIP는 유연하지만 MCU의 RAM/CPU를 더 소모할 수 있습니다. W5500 같은 하드웨어 스택은 네트워크 처리를 오프로딩해, 타이밍 민감한 모션 루프에 자원을 남기는 방향에 유리합니다.

PROJECT DESCRIPTION

This firmware implements a common control architecture used in robotics and kinetic systems:
“Host controller (PC) → network commands → embedded real-time actuation.”

The network interface is W5100/W5500-based Ethernet, and the control protocol is OSC (Open Sound Control).
It also unifies multiple product variants—such as STEP400/STEP800 and STEP100/200, which differ in hardware configuration and detailed features—into a single shared codebase, instead of maintaining separate firmware projects for each model.

What is OSC (Open Sound Control)?

OSC is a real-time control message format/protocol originally widely used in music, media, and interactive art. It typically runs over UDP and has the following characteristics:

Address-based routing (Address Pattern): Commands are identified using path-like addresses, e.g. /motor/1/pos, /axis/0/vel.

Type tags + binary payload: Clear data types (int/float/string, etc.) make parsing and extension straightforward.

Bundle support: Multiple messages can be grouped together, and bundles may include time tags (timing information).

Rich ecosystem: Easy to send/receive from many PC tools (e.g., TouchDesigner, Max, Processing, Python, etc.).

In short, OSC is well-suited for streaming multiple control parameters in real time while remaining clean and extensible.

Core Goal

The key idea is to offload network stack overhead from the MCU, leaving more time and memory for the motion-control loop.

The W5500 provides Hardwired TCP/IP (reducing CPU/RAM load compared to a software stack) and includes an internal 32 KB buffer and 8 hardware sockets, making it a good fit for building UDP-based command and status flows.

It also supports non-standard hardware configurations—for example, allowing the W5500 CS pin to be configured per board.

Architecture (OSC → Motion → Driver)

Data flow

PC / host controller → sends OSC messages over UDP

W5100/W5500 → receives and buffers the UDP payload

SAMD MCU → parses OSC → updates per-axis targets (position/velocity/acceleration)

L6470 / PowerSTEP01 → drives the motors

Design point

To prevent the OSC receive loop from disturbing motion-control timing, networking is often handled as “read quickly, then queue”—an approach that benefits from Internet offload.

Image source: AI-generated

FAQ (3)

1) Why use the W5500?

On wired Ethernet, you want reliable UDP/OSC handling while the MCU focuses on motion calculations and driver control. The W5500 offers hardware TCP/IP, 32KB buffer, and 8 sockets, enabling a design that reduces MCU load compared to a pure software stack.

2) What are the advantages of OSC (UDP) in robotics?

OSC fits real-time control patterns where you want to stream commands quickly. UDP can keep latency low because it avoids connection management and retransmission overhead, but it can drop packets—so application-level safeguards (e.g., sequence numbers/timeouts) may be needed.

3) How does this differ from a software stack like LwIP?

LwIP is flexible, but it can consume more MCU RAM/CPU. A hardware-stack approach (like the W5500) offloads network processing, leaving more resources for timing-sensitive motion loops.