Wiznet makers

Overview

Honorat GBEDAGBE is a GitHub maker with public C firmware repositories, including this STM32 datalogger and a gesture-control robotic arm project. This repository defines an intelligent industrial datalogger concept for predictive maintenance, using an STM32F407VET6 as the controller and a WIZnet W5500 as the intended wired Ethernet interface for Modbus TCP and a small web interface.

The important reading is that this is an early STM32CubeIDE scaffold, not a finished industrial firmware release. The README describes a multi-physics maintenance node for pumps, motors, compressors, fans, and gearboxes. The CubeMX project already assigns SPI1 and W5500 control pins, while the actual WIZnet driver, Modbus TCP task, web server, TinyML model, and sensor acquisition logic still need to be added.

Generated technical diagram: the planned datalogger path from machine sensors to STM32F407 and W5500 wired Ethernet.

System Configuration

The documented hardware stack starts with an STM32F407VET6, a Cortex-M4 microcontroller running at 168 MHz. The sensing side is built around an MPU6050 accelerometer for vibration, a DS18B20 sensor for surface temperature, and an ACS712-30A current sensor for motor-current monitoring. The README also lists a microSD module for local CSV logs, a 24 V to 5 V DC-DC converter, and a safety relay for machine cut-off during critical alerts.

The W5500 appears as the Ethernet module for Modbus TCP and the embedded web server. In the CubeMX output, SPI1 is enabled on PA5, PA6, and PA7, while PB0 is labeled W5500_CS and PE2 is labeled W5500_RST. That is concrete hardware-target evidence: the repository is already shaped around a W5500 SPI module, even though the network driver is not yet implemented.

The software scaffold includes STM32 HAL, FreeRTOS CMSIS_V2, FATFS, ADC1, I2C1, SPI1, USART2, and generated GPIO setup. The inspected firmware currently initializes peripherals and starts a default FreeRTOS task. The README lists TensorFlow Lite for Microcontrollers, Modbus TCP, a WIZnet driver, Python training scripts, and a web HMI, but those files are not present in the current source tree.

System Architecture and Data Flow

The intended architecture is straightforward. Vibration, temperature, and current signals enter the STM32 through I2C, OneWire/GPIO, and ADC paths. The MCU is meant to process those samples locally, store logs to a microSD card through FATFS, run anomaly logic, and publish industrial data through W5500 wired Ethernet. The network side would then expose values to an HMI, PLC, SCADA tool, or maintenance dashboard through Modbus TCP or a browser.

Generated technical diagram: source-backed architecture, with the W5500 network path separated from the still-missing Modbus and web implementation.

What Is Implemented Today

The repository is strongest as a starting scaffold. The STM32CubeIDE project, linker scripts, generated HAL drivers, FreeRTOS wrapper, FATFS setup, and pin definitions are present. main.c initializes GPIO, ADC1, I2C1, SPI1, USART2, and FATFS, then starts the scheduler. freertos.c creates only the default task. main.h and gpio.c show the W5500 reset and chip-select pins.

That matters because many embedded Ethernet projects start with the pin map and peripheral setup before adding the WIZnet stack. Here, the W5500 is already reserved in the hardware configuration, so the next firmware milestone is clear: add the WIZnet ioLibrary or another W5500 driver, bind it to the STM32 SPI callbacks, define the Modbus TCP register map, and move sensor acquisition into real FreeRTOS tasks.

Generated technical diagram: implemented CubeMX pieces versus documented plans and missing runtime code.

Role of the WIZnet Chip

The W5500 is the intended industrial Ethernet bridge for the datalogger. In a completed version, it would handle the TCP/IP stack in hardware while the STM32 focuses on sensor sampling, anomaly detection, SD logging, and relay decisions. This is a good fit for predictive maintenance because maintenance nodes often sit near motors and pumps where deterministic wired Ethernet is easier to trust than Wi-Fi.

For this repository, the exact claim must stay narrow. The W5500 is documented in the README and component notes, and the CubeMX firmware reserves W5500 pins. However, the inspected source does not yet include socket calls, WIZnet register access, Modbus TCP handling, or web-server code. So the post treats the W5500 path as a source-backed design target and hardware scaffold, not as a verified runtime TOE implementation.

Predictive Maintenance Angle

The application target is useful. Vibration, surface temperature, and motor current are common signals for rotating-machine maintenance. The README describes fault categories such as imbalance, misalignment, bearing defects, cavitation, and electrical faults, plus remaining useful life estimation. If implemented, the W5500 would make those machine-health values available on a wired plant network while the STM32 keeps a local event log.

The current repo is not yet enough to validate the AI or diagnosis claims. There are no model files, no Python training scripts, no feature-extraction code, and no inference loop in the firmware. The value today is the system framing: it connects W5500 Ethernet with an STM32 predictive-maintenance node and shows where a practical industrial monitoring firmware could grow.

Where It Fits - Value and Limits

This is worth featuring as an early design scaffold for industrial monitoring. It is not another simple sensor demo: the intended system combines machine sensing, local storage, FreeRTOS scheduling, safety output, W5500 Ethernet, Modbus TCP, and TinyML. That mix is directly relevant to edge maintenance devices and small plant-floor gateways.

The limits are equally important. There is no repository-level license, no real hardware photo, no schematic, no WIZnet driver source, no Modbus implementation, no web HMI files, and no TinyML runtime. Anyone reusing it should treat it as a CubeMX and documentation base, then add the missing W5500 driver and application tasks before calling it a working datalogger.

Related WIZnet Maker Projects

STM32 + W5500 Modbus TCP Server: A Practical Ethernet Reference for Industrial Devices is the closest protocol reference. Both projects use STM32 plus W5500 for industrial Ethernet, and both point toward Modbus TCP. The difference is maturity: that Maker post focuses on a Modbus TCP server implementation, while this datalogger repository currently provides the predictive-maintenance hardware scaffold and pin assignment.

LoRa Datalogger with W5500 Host is related from the datalogging side. It shows W5500 as the wired host interface for collected field data. The predictive-maintenance repo is different because its data source is rotating-machinery health signals and its intended network protocol is Modbus TCP rather than a LoRa gateway path.

How to Build an Interrupt-Driven W5500 UDP Server on STM32F4 with FreeRTOS and ioLibrary is useful for the missing firmware milestone. It shows how a W5500 driver can be bound into STM32F4 and FreeRTOS using WIZnet socket APIs. That is exactly the kind of runtime layer this datalogger scaffold still needs.

FAQ

Q. Is this a complete predictive-maintenance datalogger? No. It is best read as an STM32CubeIDE scaffold and system concept. The CubeMX project, peripheral initialization, W5500 pins, FreeRTOS wrapper, and FATFS setup exist, but the application tasks and network services are still missing.

Q. What does the project use the W5500 for? The README describes W5500 as the Ethernet module for Modbus TCP and an embedded web server. The CubeMX project assigns W5500 control pins over SPI, but the inspected firmware does not yet include the WIZnet driver or socket code.

Q. Why is W5500 useful in this kind of maintenance device? A plant-floor maintenance node benefits from wired Ethernet because it is stable, deterministic, and easy to connect to PLC, HMI, SCADA, or gateway infrastructure. W5500 would also offload TCP/IP handling from the STM32 once the driver is added.

Q. What should be implemented next? The next steps are WIZnet ioLibrary integration, SPI callback binding, W5500 initialization, a Modbus TCP register map, FreeRTOS tasks for sensor acquisition, SD logging, and the TinyML inference loop.

Q. What should readers avoid assuming? They should not assume that the autoencoder, RUL estimation, fault diagnosis, web server, or Modbus TCP service is already running. Those features are documented design goals, not verified runtime behavior in the current repo.

한국어 (Korean)

개요

Honorat GBEDAGBE는 C 기반 공개 펌웨어 저장소를 올리는 GitHub 메이커이며, 이 STM32 datalogger와 제스처 제어 로봇팔 프로젝트를 공개해 두었습니다. 이 저장소는 STM32F407VET6을 메인 컨트롤러로 쓰고, WIZnet W5500을 Modbus TCP와 간단한 웹 인터페이스용 유선 Ethernet 경로로 배치한 산업용 예측정비 datalogger 컨셉입니다.

중요한 점은 이 저장소가 완성된 산업용 firmware가 아니라 초기 STM32CubeIDE scaffold라는 것입니다. README는 펌프, 모터, 컴프레서, 팬, 기어박스의 진동, 온도, 전류 이상을 감지하는 구조를 설명합니다. CubeMX 프로젝트에는 SPI1과 W5500 제어 핀이 잡혀 있지만, WIZnet driver, Modbus TCP task, web server, TinyML model, sensor acquisition logic은 아직 추가되어야 합니다.

생성 기술 다이어그램: 기계 센서에서 STM32F407과 W5500 유선 Ethernet으로 이어지는 계획된 datalogger 경로.

시스템 구성

문서에 적힌 하드웨어 스택은 168 MHz Cortex-M4 MCU인 STM32F407VET6을 중심으로 합니다. 센서 쪽에는 진동 측정용 MPU6050, 표면 온도 측정용 DS18B20, 모터 전류 측정용 ACS712-30A가 배치됩니다. README는 로컬 CSV 로그를 위한 microSD 모듈, 24 V to 5 V DC-DC converter, critical alert 상황에서 기계를 차단하기 위한 safety relay도 함께 언급합니다.

W5500은 Modbus TCP와 embedded web server를 위한 Ethernet module로 등장합니다. CubeMX 출력에서는 SPI1이 PA5, PA6, PA7에 설정되어 있고, PB0은 W5500_CS, PE2는 W5500_RST로 표시됩니다. 즉 네트워크 driver는 아직 없지만, 저장소 자체는 이미 W5500 SPI module을 염두에 둔 하드웨어 설정을 포함하고 있습니다.

소프트웨어 scaffold에는 STM32 HAL, FreeRTOS CMSIS_V2, FATFS, ADC1, I2C1, SPI1, USART2, GPIO 초기화가 들어 있습니다. 현재 firmware는 주변장치를 초기화하고 기본 FreeRTOS task를 시작하는 수준입니다. README에는 TensorFlow Lite for Microcontrollers, Modbus TCP, WIZnet driver, Python training scripts, web HMI가 적혀 있지만, 해당 구현 파일은 현재 소스 트리에서 확인되지 않았습니다.

시스템 아키텍처와 데이터 흐름

의도된 구조는 명확합니다. 진동, 온도, 전류 신호가 I2C, OneWire/GPIO, ADC 경로로 STM32에 들어오고, MCU는 이 데이터를 로컬에서 처리하고 FATFS를 통해 microSD에 로그를 남기며 이상 감지 로직을 수행합니다. 이후 W5500 유선 Ethernet을 통해 HMI, PLC, SCADA, maintenance dashboard가 Modbus TCP나 브라우저로 데이터를 읽는 구조입니다.

생성 기술 다이어그램: W5500 네트워크 경로와 아직 구현되지 않은 Modbus/web layer를 분리해 표시한 source-backed architecture.

현재 구현된 범위

이 저장소의 강점은 시작점이 되는 scaffold입니다. STM32CubeIDE project, linker script, generated HAL driver, FreeRTOS wrapper, FATFS setup, pin definition이 들어 있습니다. main.c는 GPIO, ADC1, I2C1, SPI1, USART2, FATFS를 초기화한 뒤 scheduler를 시작합니다. freertos.c에는 default task만 있고, main.h와 gpio.c에는 W5500 reset과 chip-select 핀이 보입니다.

이 점은 의미가 있습니다. 많은 embedded Ethernet 프로젝트는 WIZnet stack을 올리기 전에 pin map과 peripheral setup부터 맞춥니다. 이 저장소에서는 W5500이 이미 hardware configuration 안에 예약되어 있으므로 다음 firmware milestone도 분명합니다. WIZnet ioLibrary나 다른 W5500 driver를 추가하고, STM32 SPI callback에 묶고, Modbus TCP register map을 정의하고, sensor acquisition을 실제 FreeRTOS task로 옮겨야 합니다.

생성 기술 다이어그램: 구현된 CubeMX 요소와 문서상의 계획, 아직 빠진 runtime code를 구분한 그림.

WIZnet 칩의 역할

W5500은 이 datalogger의 산업용 Ethernet bridge로 계획되어 있습니다. 완성 버전에서는 TCP/IP stack을 W5500 하드웨어가 처리하고, STM32는 센서 샘플링, 이상 감지, SD logging, relay decision에 집중할 수 있습니다. 예측정비 node는 모터나 펌프 근처에 설치되는 경우가 많기 때문에, Wi-Fi보다 신뢰하기 쉬운 유선 Ethernet이 잘 맞습니다.

다만 이 저장소에서 말할 수 있는 범위는 좁게 잡아야 합니다. W5500은 README와 component 문서에 있고, CubeMX firmware도 W5500 pin을 예약합니다. 하지만 검사한 source에는 socket call, WIZnet register access, Modbus TCP 처리, web-server code가 아직 없습니다. 따라서 이 글에서는 W5500 경로를 검증된 runtime TOE 구현이 아니라, 근거가 있는 설계 목표와 hardware scaffold로 다룹니다.

예측정비 관점

응용 목표 자체는 좋습니다. 진동, 표면 온도, 모터 전류는 회전기계 정비에서 흔히 쓰는 신호입니다. README는 imbalance, misalignment, bearing defect, cavitation, electrical fault 같은 fault category와 remaining useful life estimation을 설명합니다. 구현이 완성된다면 W5500은 이런 machine-health 값을 유선 plant network에 제공하고, STM32는 local event log를 유지하는 역할을 맡게 됩니다.

현재 repo만으로 AI나 diagnosis 기능을 검증할 수는 없습니다. model file, Python training script, feature extraction code, firmware inference loop가 없습니다. 현재 가치는 W5500 Ethernet과 STM32 예측정비 node를 연결하는 system framing과, 실제 산업용 monitoring firmware가 자랄 수 있는 기본 구조를 보여준다는 데 있습니다.

적용 가치와 한계

이 프로젝트는 산업용 모니터링을 위한 초기 설계 scaffold로 소개할 만합니다. 단순 센서 데모라기보다 machine sensing, local storage, FreeRTOS scheduling, safety output, W5500 Ethernet, Modbus TCP, TinyML을 한 시스템 안에 배치하려는 방향이 있습니다. 이 조합은 edge maintenance device나 작은 plant-floor gateway와 직접 연결됩니다.

한계도 분명합니다. repository-level license가 없고, 실제 hardware photo, schematic, WIZnet driver source, Modbus implementation, web HMI file, TinyML runtime이 없습니다. 재사용하려는 사람은 이를 CubeMX와 문서 기반의 출발점으로 보고, W5500 driver와 application task를 추가한 뒤에야 동작하는 datalogger라고 부를 수 있습니다.

관련 WIZnet Maker 프로젝트

STM32 + W5500 Modbus TCP Server: A Practical Ethernet Reference for Industrial Devices 는 가장 가까운 protocol reference입니다. 두 프로젝트 모두 STM32와 W5500을 산업용 Ethernet에 쓰고, Modbus TCP 방향을 가집니다. 차이는 성숙도입니다. 해당 Maker 글은 Modbus TCP server 구현에 집중하고, 이 datalogger 저장소는 예측정비 hardware scaffold와 pin assignment 단계에 머물러 있습니다.

LoRa Datalogger with W5500 Host 는 datalogging 관점에서 관련이 있습니다. 이 글은 수집된 field data의 유선 host interface로 W5500을 쓰는 사례를 보여줍니다. 예측정비 repo는 데이터 원천이 회전기계 health signal이고, 의도된 network protocol이 LoRa gateway 경로가 아니라 Modbus TCP라는 점이 다릅니다.

How to Build an Interrupt-Driven W5500 UDP Server on STM32F4 with FreeRTOS and ioLibrary 는 이 저장소의 다음 firmware milestone에 참고하기 좋습니다. STM32F4와 FreeRTOS에 W5500 driver를 연결하고 WIZnet socket API를 쓰는 방법을 보여주기 때문입니다. 이 datalogger scaffold에는 바로 그런 runtime layer가 아직 필요합니다.

FAQ

이 프로젝트는 완성된 예측정비 datalogger인가요? 아닙니다. 현재는 STM32CubeIDE scaffold와 system concept로 보는 것이 맞습니다. CubeMX project, peripheral initialization, W5500 pin, FreeRTOS wrapper, FATFS setup은 있지만 application task와 network service는 아직 없습니다.

W5500은 어디에 쓰이나요? README는 W5500을 Modbus TCP와 embedded web server용 Ethernet module로 설명합니다. CubeMX project도 SPI 기반 W5500 control pin을 잡고 있지만, 검사한 firmware에는 WIZnet driver나 socket code가 아직 없습니다.

이런 maintenance device에서 W5500이 왜 유용한가요? 공장 설비 주변의 maintenance node는 PLC, HMI, SCADA, gateway와 안정적으로 연결되어야 하기 때문에 유선 Ethernet이 잘 맞습니다. W5500 driver가 추가되면 TCP/IP 처리를 STM32에서 덜어낼 수 있다는 장점도 있습니다.

다음에 무엇을 구현해야 하나요? WIZnet ioLibrary integration, SPI callback binding, W5500 initialization, Modbus TCP register map, sensor acquisition FreeRTOS task, SD logging, TinyML inference loop가 필요합니다.

독자가 오해하면 안 되는 부분은 무엇인가요? autoencoder, RUL estimation, fault diagnosis, web server, Modbus TCP service가 이미 동작한다고 보면 안 됩니다. 이 기능들은 현재 repo에서 검증된 runtime behavior가 아니라 문서화된 design goal입니다.