Wiznet makers

Summary

Analog Devices no-OS is a bare-metal embedded software framework for running ADI device drivers and reference projects on microcontrollers, FPGAs, and processors that do not use Linux or a full operating system. In this project, WIZnet W5500 is used as a wired Ethernet socket backend: no-OS provides its own W5500 driver and network adapter instead of directly using WIZnet ioLibrary, allowing no-OS applications to access TCP/UDP networking through the project’s generic socket interface.

What the Project Does

The no-OS project exists because many Analog Devices parts are used as peripherals attached to external digital engines such as FPGAs, microprocessors, or microcontrollers. ADI’s README explains that Linux-based processor support is already a major area of work, but microcontroller support is fragmented because the MCU market is diverse. no-OS addresses that gap by providing C drivers, platform abstractions, build support, and reference projects for lower-end processors that cannot run Linux or are not running a specific operating system.

At the framework level, no-OS defines common APIs for bare-metal peripherals such as GPIO, SPI, I2C, timers, interrupts, and communication interfaces. That lets the same ADI device driver logic run across multiple MCU and FPGA platforms with different vendor SDKs underneath. The W5500 support follows this same pattern: low-level SPI and GPIO access goes through no-OS platform descriptors, while the network layer exposes socket-like functions to higher-level application code.

The W5500 integration is split into two layers. The first layer is drivers/net/w5500/, which implements register access, reset/setup, IP/MAC configuration, link status, and socket commands for the W5500 chip. The second layer is network/w5500_network/, which maps no-OS generic socket operations onto W5500 hardware sockets. This is not just a copied WIZnet ioLibrary example; it is an ADI no-OS-style driver plus an adapter layer designed to fit the existing no-OS networking API.

Where WIZnet Fits

The WIZnet product used here is the W5500 Ethernet controller. W5500 is a hardwired TCP/IP stack controller with an SPI interface up to 80 MHz, an embedded 10/100 Ethernet MAC and PHY, 8 independent sockets, and 32 KB of internal memory for Tx/Rx buffers. WIZnet’s own documentation lists ioLibrary_Driver as the official MCU-independent driver library, but this no-OS repository implements its own W5500 driver instead of calling ioLibrary APIs.

The evidence is visible in the code structure. drivers/net/w5500/w5500.c includes w5500.h, no_os_alloc.h, and no_os_delay.h; the W5500 device structure stores no_os_spi_desc, reset GPIO, interrupt GPIO, MAC address, retry settings, and socket state. There are no wizchip_conf.h, socket.h, reg_wizchip_*, or ctlnetwork() style ioLibrary calls in the inspected W5500 driver path. Instead, the driver builds W5500 SPI frames directly and calls no_os_spi_transfer().

Architecturally, W5500 gives no-OS a hardware TCP/UDP Ethernet path without requiring Linux networking. That fits the project’s purpose: small embedded targets can run ADI measurement, control, or instrumentation examples while still exposing network services through a stable wired interface. The W5500 handles Ethernet MAC/PHY and socket-oriented TCP/UDP behavior, while no-OS keeps the application-facing API portable across platforms.

Implementation Notes

The first important implementation point is that ADI wrote a W5500 register driver that directly constructs the chip’s SPI command frame. In drivers/net/w5500/w5500.c, w5500_reg_write() creates the address bytes, W5500 control byte, payload, and then sends the transaction through the no-OS SPI abstraction.

/* drivers/net/w5500/w5500.c */

spi_tx[0] = W5500_BYTE_HIGH(addr);
spi_tx[1] = W5500_BYTE_LOW(addr);
spi_tx[2] = W5500_BSB(block) | W5500_RWB_WRITE | W5500_OM_VDM;

struct no_os_spi_msg xfer = {
	.tx_buff = spi_tx,
	.rx_buff = NULL,
	.bytes_number = 3 + len,
	.cs_change = 1,
};

return no_os_spi_transfer(dev->spi, &xfer, 1);

This snippet matters because it shows the driver is not delegating W5500 access to ioLibrary. The code forms the W5500 SPI transfer format itself and routes the transaction through no-OS SPI, which is the correct design for a portable bare-metal framework.

The second important point is that the W5500 driver is wrapped by a no-OS network interface. In network/w5500_network/w5500_network.c, w5500_network_init() assigns W5500-backed functions into the generic net_if table.

/* network/w5500_network/w5500_network.c */

dev->net_if.net = dev;
dev->net_if.socket_open = w5500_net_socket_open;
dev->net_if.socket_close = w5500_net_socket_close;
dev->net_if.socket_connect = w5500_net_socket_connect;
dev->net_if.socket_send = w5500_net_socket_send;
dev->net_if.socket_recv = w5500_net_socket_recv;
dev->net_if.socket_bind = w5500_net_socket_bind;
dev->net_if.socket_listen = w5500_net_socket_listen;
dev->net_if.socket_accept = w5500_net_socket_accept;

This code exists so higher-level no-OS applications can use network operations without being tightly coupled to W5500 register names. The adapter also translates generic protocols into W5500 socket modes, mapping PROTOCOL_TCP to W5500_Sn_MR_TCP and PROTOCOL_UDP to W5500_Sn_MR_UDP.

Practical Tips / Pitfalls

• Treat this as a native no-OS W5500 driver, not an ioLibrary port. Reuse no-OS SPI/GPIO configuration patterns instead of trying to initialize W5500 through wizchip_conf.h.
• Check the SPI transaction format carefully. The no-OS driver builds the W5500 address/control frame itself, so incorrect SPI mode, chip-select timing, or byte order will break all register access.
• Plan socket usage around W5500’s 8 hardware sockets. no-OS maps virtual socket IDs to physical W5500 sockets, but the chip still has a fixed socket limit.
• Use reset and interrupt pins deliberately. The w5500_dev structure supports reset GPIO and interrupt GPIO, which are useful for deterministic startup and link/event handling in field hardware.
• Size buffers according to the traffic pattern. The W5500 header defines socket buffer sizes from 1 KB to 16 KB, and the network wrapper converts requested buffer size into those W5500-supported settings.
• For industrial boards, keep W5500 SPI traces short, add proper Ethernet magnetics/ESD protection, and verify PHY link behavior under brownout and cable hot-plug conditions.

FAQ

Q: Why does no-OS use W5500?
A: W5500 gives no-OS a wired TCP/UDP Ethernet backend for bare-metal systems that do not run Linux. Its hardwired TCP/IP stack, embedded MAC/PHY, SPI host interface, 8 sockets, and internal Tx/Rx memory match the no-OS goal of supporting small embedded targets with limited software stack overhead.

Q: How does W5500 connect to the no-OS platform?
A: It connects through SPI plus optional GPIOs for reset and interrupt. The no-OS W5500 device structure stores no_os_spi_desc, no_os_gpio_desc reset, and no_os_gpio_desc interrupt handles, which lets the same W5500 driver run on different MCU platforms through no-OS platform drivers.

Q: What role does W5500 play in this project?
A: W5500 is the concrete Ethernet socket backend. The low-level driver handles W5500 registers, IP/MAC configuration, link status, and socket commands, while w5500_network.c plugs those operations into no-OS socket_open, socket_connect, socket_send, socket_recv, bind, listen, and accept callbacks.

Q: Can beginners follow this implementation?
A: It is better suited for embedded developers who already understand C, SPI peripherals, Ethernet addressing, and socket concepts. Beginners can still learn from it, but they should start by studying the no-OS SPI/GPIO abstraction and the W5500 register map before modifying the network wrapper.

Q: How is this different from using WIZnet ioLibrary?
A: WIZnet ioLibrary is the official MCU-independent WIZnet driver library, but this repository does not use it in the inspected W5500 path. ADI’s implementation defines its own W5500 register constants, device structures, SPI read/write routines, and socket mapping layer so W5500 behaves like a native no-OS network backend.