Wiznet makers

Thumbnail Image: AI-generated image

ERIC888_RTOS: a dual-STM32F429 industrial protection controller architecture with FreeRTOS, W5500 Ethernet, and a split between hard-real-time control and panel-side communications

Introduction

ERIC888_RTOS is not a simple STM32 demo project. The reviewed repository materials and uploaded ZIP snapshot show a dual-board industrial controller architecture built around two STM32F429-class boards: one board is dedicated to fast sampling, protection logic, and trip execution, while the other is dedicated to display, networking, storage, and remote communications. In the project’s own architecture notes, this split is presented as a deliberate separation between microsecond-level hard-real-time protection and a richer human-machine / protocol / storage layer. That system choice fits the STM32F429 family well, because the device line combines a 180 MHz Cortex-M4 with DSP/FPU support, graphics-oriented LTDC features, and external-memory capability. (STMicroelectronics)

What makes the repository especially interesting is that it already spans several industrial design concerns at once: power-signal acquisition, real-time protection, fault recording, RS485/Modbus, inter-board protocol exchange, panel-side W5500 Ethernet, 4G, GPS, SD storage, and a planned GUI path based on LVGL. So the safest description is not “an RTOS example,” but rather an early industrial controller platform under active architectural build-out.

Quick background

To make sense of this project, three short ideas help.

First, this is the kind of system that sits close to electrical protection and fast transfer logic rather than ordinary edge sensing. The A-side hardware is built around an AD7606-class simultaneous-sampling ADC path, relay or switch-driving outputs, and feedback lines that confirm breaker or switch position. Analog Devices describes the AD7606 family as an 8-channel, 16-bit, simultaneous-sampling data-acquisition ADC with integrated analog front-end features and both serial and parallel interfaces, which explains why it is attractive in power-quality, protection, and fault-analysis designs. (Analog Devices)

Second, the project uses a two-board split because “fast protection” and “rich communications/UI” often pull in opposite design directions. A hard-real-time control path wants deterministic response and minimal blocking. A panel-side system, by contrast, wants a screen stack, storage, network protocols, and remote services. ERIC888’s architecture notes make that split explicit: the Calc board handles the speed-critical side, while the Panel board handles display, networking, and storage. In plain language, one board makes the fast decision, while the other explains, records, and publishes the result.

Third, some of the protocol names deserve a simple explanation. Modbus RTU is the long-established serial version of Modbus, commonly used over RS485. Modbus TCP is the Ethernet/TCP version of the same application-layer model. The Modbus Organization describes Modbus as an application-layer protocol used across serial and Ethernet/TCP networks. IEC 61850, by contrast, is not just a simple register protocol. It is a much broader power-automation standard built around data models and communication services for interoperable intelligent electronic devices in substations and related automation systems. (Modbus Organization)

What this project is

AI-generated image

At a high level, the repository is organized as a multi-board industrial controller workspace with three clear layers: an A-board control path, a B-board panel/communications path, and a shared inter-board protocol layer. The workspace README describes the A board as the STM32F429 side for AD7606 FMC acquisition, protection algorithms, and relay control, the B board as the side for LVGL touch display, W5500 Ethernet, and 4G remote communications, and a shared protocol directory as the glue between them.

The broader architecture document reinforces that picture. It places the A board in charge of high-speed sampling, protection calculation, and instantaneous trip execution, and the B board in charge of LCD display, external protocol communications, and data storage, with SPI4 over isolated RS-422 acting as the bridge between them. That bridge matters because it means the project is not trying to put every function on one CPU and hope task scheduling solves the rest. Instead, it is separating control-plane urgency from management-plane complexity at the hardware level.

The hardware reference adds more practical detail. It shows the A board tied to the AD7606 parallel acquisition path, analog front-end circuitry, K-switch drive chains, RS485, flash, NAND, and SDRAM, while the B board carries the LCD path, touch controller, W5500, EC20 4G module, GPS, SDIO, and two RS485 channels. In other words, the repository is describing a complete industrial product architecture, not just a development-board firmware sample.

There is also an important maturity detail. Some of the panel-board planning documents still speak in “to be initialized” or “to do” language, especially around full B-board bring-up. But the repository already contains concrete W5500 register-driver and socket-layer code in the panel-board tree. So the project is not purely aspirational on the Ethernet side; it is partly implemented, even if the broader B-board application stack is still incomplete.

So the safest curator description is this: ERIC888_RTOS is an early-stage industrial controller platform that already combines real-time protection firmware, protocol handling, inter-board transport, and a real W5500 Ethernet implementation, even though the panel-side product layer is still under construction.

Author & public footprint

The public GitHub footprint reviewed here is broader than one embedded controller repository. The same account also hosts AI-PM, which is presented as an AI-driven project-management SaaS built with FastAPI, Gemini, PostgreSQL, Redis, and enterprise messaging integration, and biaobiao, which is presented as an AI-assisted bid-document platform using FastAPI, Next.js, PostgreSQL, RAG, and Gemini. That does not by itself prove a single unified industrial product company, but it does show a maintainer profile spanning industrial/embedded engineering on one side and AI-enabled business software tooling on the other.

That broader context matters curatorially because ERIC888_RTOS does not look like an isolated firmware upload from a hobby account. It sits inside a wider public pattern of technically ambitious project work, although the public materials reviewed here do not yet establish a clearly branded industrial product organization around ERIC888 itself. The available materials therefore support describing the project as serious systems work with a broader builder profile behind it, while still being careful not to overstate commercial deployment.

How it works

AI-generated image

The visible A-board firmware is the clearest place to understand the real operating model. In freertos.c, the control side is organized into separate FreeRTOS tasks for communications, calculation/protection, fault storage, and monitoring/watchdog supervision. The communications task initializes RS485 Modbus RTU and the SPI4 slave path. The calculation task blocks on ADC-ready notification, processes batches through DSP logic, and can trigger a system-wide trip. The storage task handles fault recording, and the monitor task feeds the watchdog and checks timing statistics. This is the shape of a real controller runtime, not a single-loop sensor demo.

For non-specialists, the control flow can be summarized as: sample → analyze → trip if necessary → record the event → expose status to other systems. The A board receives fast analog data from the AD7606 path, performs batch DSP and protection checks, and publishes current system state over its local communications paths. The same source file even includes an expected interrupt-rate check around the project’s 25.6 kHz acquisition logic, which shows that sampling regularity is treated as a design concern rather than a casual byproduct.

The A-board communication path that is clearly implemented today is Modbus RTU over RS485. The Modbus header states that the A board is a Modbus RTU slave and lists supported function codes for reading holding registers and writing selected configuration values such as thresholds. That means the project already exposes its internal results through a familiar industrial serial interface, which is often exactly how protection or measurement equipment first becomes useful in a broader system. (Modbus Organization)

The B-board side is currently more architectural than fully integrated, but its role is already well defined. The reviewed files describe it as the panel and communications side that should read data from A over SPI4, render waveforms and status through LVGL, use W5500 Ethernet for Modbus TCP and potentially IEC 61850, store records to SD, and extend the system outward through 4G and GPS. That makes the B board the system’s outward-facing interface, while the A board remains the deterministic protection engine.

Communications architecture and the WIZnet path

The communication architecture is easiest to understand as three layers.

The first layer is the field/control layer on the A board. This is where RS485 Modbus RTU and the core protection data live. It is close to the sampling and trip logic, and it is the only communication path in the reviewed code that is already clearly active inside the main FreeRTOS runtime.

The second layer is the inter-board bridge. The architecture documents define SPI4 over isolated RS-422 as the high-speed channel between the Calc and Panel boards. That bridge is what allows the project to keep real-time protection isolated from the cost of UI and networking, while still making high-rate data and state information available to the B board.

The third layer is the panel-side outward communications layer, and this is where WIZnet enters the picture. The hardware reference places a W5500 on the B board over SPI2, with dedicated CS, INT, and RESET lines and an HR911105A integrated RJ45/transformer path. The panel README and W5500 header comments associate that Ethernet side with Modbus TCP and an intended IEC 61850 direction. In system terms, the W5500 is therefore not part of the microsecond protection loop itself. It is part of the LAN-facing management and protocol side of the platform.

That distinction matters. The W5500 path is being used where deterministic Ethernet connectivity is valuable for panel-side protocol exposure, not where the controller must make its fastest trip decision. This is a practical use of WIZnet hardware in industrial architecture: the Ethernet offload device helps the communication side, while the protection side stays isolated and timing-focused. W5500 itself is designed as a hardwired TCP/IP controller with an SPI interface, integrated 10/100 MAC/PHY, and eight hardware sockets, so that general model fits the repository’s intended partitioning well. (WIZnet Documentation)

One more point is worth making early because it connects to the later SPE discussion. The current visible hardware is standard RJ45-based 10/100 Ethernet, not Single Pair Ethernet. The board documentation explicitly ties W5500 to an integrated RJ45 transformer module, while current SPE platforms are built around different PHY/media hardware such as 10BASE-T1L devices. So ERIC888’s current Ethernet path is conventional industrial Ethernet, even though the broader architectural ideas may still be relevant to future SPE-oriented systems. (WIZnet Documentation)

TOE / ioLibrary Driver or lwIP?

The visible WIZnet path is best described as TOE-style, custom direct-register W5500 access, not an lwIP build.

W5500 itself belongs to WIZnet’s hardwired TCP/IP family. WIZnet’s documentation describes the chip as a hardware TCP/IP controller with socket offload, and WIZnet’s official ioLibrary_Driver is the company’s MCU-independent Internet Offload Library for chips such as the W5500. (WIZnet Documentation)

But that is not the same as saying this repository imports WIZnet’s official ioLibrary package directly. The reviewed panel-board sources contain their own custom bsp_w5500.c/.h and bsp_w5500_socket.c/.h files. These files manually define W5500 common-register addresses, socket-register offsets, buffer block-select values, and socket commands such as OPEN, LISTEN, SEND, and RECV. In other words, the code clearly follows the same basic hardware-socket model as WIZnet’s offload approach, but it does so through a project-specific implementation rather than by pulling in the official ioLibrary tree unchanged. (WIZnet Documentation)

It is also not a visible lwIP integration in the current code snapshot. The architecture document mentions LwIP as part of the broader planned B-board core, but the actual panel-board code reviewed here centers on direct W5500 register and socket handling. The panel board’s HAL configuration also leaves STM32’s native HAL_ETH module disabled, which further supports the reading that the current implementation is not built around the STM32 on-chip Ethernet MAC plus lwIP path.

So the most accurate classification is this:

The reviewed ERIC888 panel-side Ethernet code uses a custom, ioLibrary-style TOE path on top of W5500 hardware; it is not a visible lwIP integration, and it is not a verbatim import of WIZnet’s official ioLibrary_Driver. (WIZnet Documentation)

The same care is needed when describing protocol maturity. The W5500 header comments and panel-side docs explicitly mention Modbus TCP and IEC 61850, but the reviewed source files that are clearly concrete today are the W5500 register driver and the generic socket layer. That is enough to confirm a real Ethernet transport foundation, but not enough to claim that a complete IEC 61850 application stack is already visible in the current repository snapshot. (IEC 61850)

Why it matters

ERIC888_RTOS matters because it follows a pattern that is common in serious protection and power-automation equipment, but much less common in hobby or demo firmware: it separates the fast decision-making path from the communications and operator-interface path at the hardware level. The reviewed materials show an A board built around high-speed acquisition, DSP-style batch processing, trip logic, and event recording, while the B board is reserved for UI, Ethernet, 4G, GPS, SD storage, and protocol-facing services. That is a strong architectural signal. It means the project is not merely trying to “add networking” to a controller; it is trying to keep protection timing intact while still exposing the system to operators and external networks.

That design direction also fits the chosen silicon and analog front end. STM32F429 devices are strong candidates for this kind of split because they combine a 180 MHz Cortex-M4 with DSP/FPU capability, external-memory support, rich communication peripherals, and graphics-oriented hardware such as LTDC and DMA2D, while the AD7606 family is explicitly positioned for power-line monitoring and protection systems and other simultaneous-sampling industrial acquisition workloads. In practical terms, that means the repository is aligned with a real embedded-control use case rather than with a generic “IoT node” pattern. (STMicroelectronics)

The other reason it matters is protocol ambition. Public sources reviewed here indicate that the project is pointed toward a combination of Modbus RTU, Modbus TCP, and an intended IEC 61850 direction. That is important because IEC 61850 sits in the world of power utility automation systems and interoperable IED-style communication, not in the world of casual Ethernet telemetry. Even though the reviewed source tree does not yet show a complete IEC 61850 stack, the architecture is clearly aiming at a class of system where power-event data, trip state, status exposure, and networked supervisory access all belong together. (IEC Webstore)

Market and industry context

There is no clean public market number for the exact niche represented by this repository — essentially a custom fast-transfer / protection / panel-control platform — so the safest market framing is adjacent context, not a direct “market size for this repo.” The closest public market references reviewed here are the substation automation and digital substation markets. One 2026 market release places the substation automation market at USD 40.04 billion in 2026, projected to reach USD 57.59 billion by 2031, while another release places the digital substation market at roughly USD 7.85 billion in 2024, projected to reach USD 11.8 billion by 2029. Those are adjacent categories, not exact matches, but they do show that the surrounding infrastructure segment is large and still expanding. (GlobeNewswire)

That adjacent fit is reinforced by the standards landscape. IEC now describes the 61850 series as covering communication networks and systems for power utility automation, and domain-specific parts of the series extend into distribution automation, DER systems, and power-quality data exchange. That matters because ERIC888’s own reviewed documents combine fast protection logic, analog acquisition, relay or switching control, fault recording, and Ethernet/serial protocol ambitions — exactly the kind of mixed control-and-communications environment where IEC 61850-adjacent thinking becomes relevant. (IEC Webstore)

The stronger industry story, then, is not “this is already a product in market,” but that it points in the same direction as ongoing grid and substation modernization: more real-time visibility, more interoperable communications, more distributed intelligence, and cleaner separation between critical control paths and management-plane networking. The market releases reviewed here explicitly tie substation automation growth to grid modernization, renewable integration, smart substation adoption, and greater need for real-time monitoring and advanced communications. ERIC888_RTOS does not yet prove commercial deployment, but its architecture is aligned with those pressures. (GlobeNewswire)

External value and author activity

AI-generated image

The public account activity reviewed here suggests that the maintainer is not operating only inside one narrow embedded-firmware lane. In addition to ERIC888_RTOS, the same account publicly presents AI-PM, an AI-driven project-management system, and biaobiao, an AI-assisted bid-document platform. Those projects live in a very different software space, but together they show a builder profile that spans industrial-control architecture on one side and enterprise or AI-backed application systems on the other. That does not prove a finished industrial product company around ERIC888, but it does suggest wider systems-thinking capability than a single isolated MCU project would imply.

From a curator’s perspective, the stronger external value today is therefore not broad public adoption but engineering value. The reviewed materials show a platform that already thinks in terms of acquisition timing, protocol boundaries, fault records, inter-board transport, storage, and network exposure. That makes it relevant as a reference architecture for OEM-style work in power switching, protection panels, distribution automation, or high-speed industrial event recording, even if the reviewed repository does not yet read as a polished public product release.

SPE applicability and future-fit

AI-generated image

The first conclusion needs to be very clear: ERIC888_RTOS does not currently implement Single Pair Ethernet. The visible hardware and code are built around a W5500 connected over SPI to a conventional integrated RJ45/magnetics path, and W5500 itself is a 10/100 Ethernet MAC/PHY hardwired TCP/IP controller designed for standard twisted-pair Ethernet rather than 10BASE-T1L or other SPE physical layers. So the current design is classic industrial Ethernet plus RS485, not SPE. (WIZnet Documentation)

However, the answer becomes more interesting at the architecture level. Public SPE sources reviewed here note that SPE is still Ethernet, with different physical-layer media, and that OSI layers 2 through 7 remain the same across Ethernet physical-layer types. That means application-layer logic such as Modbus TCP-style services does not become conceptually invalid just because the physical layer changes from RJ45-based Ethernet to SPE. In principle, a future ERIC888-style platform could keep much of its upper-layer communications model while moving to an SPE PHY or MAC-PHY design. The hardware transport would need to change, but not every network-facing software concept would have to be reinvented. (마이크로칩)

This is also where SPE becomes relevant as a greenfield or next-network opportunity. Public industry sources position SPE as a way to push Ethernet farther into the field level, simplify wiring, and reduce cost, weight, and cabling complexity in industrial OT systems. 10BASE-T1L is specifically aimed at single-pair, long-reach Ethernet, and vendor references describe links of up to 1 km for long-reach variants, while Ethernet-APL extends 10BASE-T1L into rugged two-wire field deployments, including hazardous or process environments. Those are exactly the kinds of trends that make SPE interesting in industrial infrastructure, even when a current product does not yet use it. (Single Pair Ethernet)

For ERIC888 specifically, the reviewed materials suggest that SPE would be most meaningful not on the current panel board as-is, but in a future version where the system extends beyond a local cabinet panel into distributed field I/O, long-run sensing, remote switchgear monitoring, or more granular instrument-level Ethernet nodes. That is an inference, but a grounded one: the current B board is a local display-and-comms board with RJ45 W5500, 4G, GPS, and SD, while the main control/sampling side remains close-coupled and timing-sensitive. So SPE looks less like a drop-in upgrade and more like a future architecture option if the product family moves toward more distributed field connectivity. (Single Pair Ethernet)

A final nuance is that Ethernet-APL is probably more relevant to harsh process-plant field devices than to a cabinet-local protection HMI board. Ethernet-APL is explicitly described as a ruggedized, two-wire, loop-powered physical layer based on 10BASE-T1L for process plants and hazardous areas. ERIC888, by contrast, currently reads more like a power-control / switching / protection platform than a process-transmitter platform. So the connection to SPE is real, but it is not a simple one-to-one fit. (Ethernet APL)

Quick notes

A few caveats are important.

The panel-side networking story is ahead at the transport layer but not yet fully visible at the application stack layer. The reviewed materials clearly show a custom W5500 register driver and socket layer, and the documents explicitly mention Modbus TCP and an intended IEC 61850 direction. But the currently reviewed code does not yet show a complete IEC 61850 implementation, and it should not be described as though that higher-level protocol stack is already fully present.

The project also shows an important implementation mismatch that should be stated plainly. The architecture document still mentions LwIP in the broader panel-board vision, but the visible Ethernet code path is a custom W5500 register/socket implementation, and the panel board’s HAL configuration leaves the STM32 on-chip Ethernet HAL disabled. So the most accurate reading today is that the current visible Ethernet implementation is custom W5500 TOE-style code, not a visible lwIP runtime.

Finally, the reviewed materials still read like an active engineering build-out, not a finished public appliance. The A-side real-time control flow is materially implemented, but the B-side roadmap still includes large planned blocks around LTDC, SDRAM framebuffers, touch, SDIO/FatFs, and broader protocol completion. So the project already has real technical substance, but its public maturity is still closer to a serious prototype platform than to a completed field product.

ERIC888_RTOS Project FAQ

Q. What is the ERIC888_RTOS project?

A. It is an early-stage industrial protection controller platform built on a dual-STM32F429 architecture. It runs FreeRTOS and is designed to handle power-signal acquisition, real-time electrical protection, and fault recording, alongside modern networking and display capabilities.

Q. Why does it use a dual-board architecture?

A. The project deliberately splits competing system needs to ensure reliability. The "A-board" (Calc) is strictly dedicated to microsecond-level, hard-real-time tasks like high-speed sampling and instantaneous relay tripping. The "B-board" (Panel) manages the complex, non-deterministic tasks like the LCD touchscreen, SD storage, and external network protocols.

Q. How do the two boards communicate with each other?

A. They communicate via a high-speed SPI4 bridge over isolated RS-422. This keeps the control-plane urgency completely separated from the management-plane complexity at the hardware level.

Q. What is the role of the WIZnet W5500 in this platform?

A. The W5500 chip is placed on the B-board to handle outward-facing LAN communications (such as Modbus TCP and planned IEC 61850 networking). It acts as a hardware TCP/IP offload engine, ensuring that network traffic processing does not interfere with the critical protection timing on the A-board.

Q. How is the W5500 software implemented?

A. Interestingly, it does not use an lwIP stack or a direct import of WIZnet's official ioLibrary_Driver. Instead, it uses a custom-built, direct-register and socket implementation to interact with the W5500 hardware.

Q. Does this project currently utilize Single Pair Ethernet (SPE)?

A. No. The current hardware uses standard RJ45-based 10/100 Ethernet. However, the system's OSI-layered architecture means it could theoretically adapt to SPE (like 10BASE-T1L) in the future if the platform expands into distributed, long-reach field I/O.

References

1. STMicroelectronics STM32F429/439 overview and product-family capabilities. (STMicroelectronics)
2. Analog Devices AD7606 product information and application fit for power-line monitoring and protection. (Analog Devices)
3. WIZnet W5500 overview and official ioLibrary driver documentation. (WIZnet Documentation)
4. Modbus Organization protocol specification and implementation references. (Modbus Organization)
5. IEC 61850 overview and domain extensions for power utility automation, distribution automation, DER, and power quality. (IEC Webstore)
6. SPE / 10BASE-T1L / Ethernet-APL background from Microchip, TI, the SPE Industrial Partner Network, the Ethernet Alliance, and Ethernet-APL. (마이크로칩)
7. Adjacent market context for substation automation and digital substations. (GlobeNewswire)
8. Reviewed architecture, hardware, workspace, and W5500 implementation files from the repository and uploaded ZIP snapshot.
9. Related public account activity from the same maintainer profile.
10. Reviewed source snapshot: ERIC888_RTOS-main.zip