---
title: "step-series-universal-firmware"
url: "https://maker.wiznet.io/mason/projects/step-series-universal-firmware/"
markdown_url: "https://maker.wiznet.io/mason/projects/step-series-universal-firmware/md"
type: "UCC: User Created Content"
author: "ponoor"
author_url: "https://github.com/ponoor/step-series-universal-firmware"
editor: "WIZnet"
editor_url: "https://maker.wiznet.io/"
original_author: "ponoor"
original_url: "https://github.com/ponoor/step-series-universal-firmware"
license: "MIT license (MIT)"
published: "2025-12-30"
language: "en"
tags: ["W5500"]
hardware: ["Arduino Ethernet Shield"]
likes: 0
views: 487
comments: 0
source: "WIZnet Makers (https://maker.wiznet.io/)"
---

# step-series-universal-firmware

> step-series-universal-firmware

Original author: ponoor (source: https://github.com/ponoor/step-series-universal-firmware)

## Components

- **Arduino Ethernet Shield** x 1 ([docs](https://docs.arduino.cc/retired/shields/arduino-ethernet-shield-without-poe-module))

## Documents and links

- [Github Code](https://github.com/ponoor/step-series-universal-firmware/tree/main) (code)

## Article

이 펌웨어는 원격에서 모터를 제어하기 위한 펌웨어이며, **“상위 제어기(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 유리)

![](https://maker.wiznet.io/upload/ckeditor5/865755726%5F1767351135%2Epng)

이미지 출처 : 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 UDPW5100/W5500** → receives and buffers the **UDP payloadSAMD 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**.

![](https://maker.wiznet.io/upload/ckeditor5/865755726%5F1767351341%2Epng)

**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.

---

Source: https://maker.wiznet.io/mason/projects/step-series-universal-firmware/