Alice Chen
Its hardwired IP stack supports IPv4, not IPv6. If dual-stack operation is required, WIZnet's W6100 is a relevant architecture comparison. Moving to it requires a separate hardware and firmware review; do not assume that a module compatibility statement or similar package establishes a drop-in replacement for a W5500 board.
No. The SPI clock is an interface capability. The datasheet qualifies 80 MHz as theoretical design speed and identifies 33.3 MHz as its tested guaranteed level with stable waveforms. Higher clocks need board-level signal-integrity review. Every transaction also includes overhead, and host scheduling and network behavior impose further limits. Benchmark the actual traffic and MCU workload rather than turning a clock label into a throughput promise.
The datasheet provides 16 kbytes for transmit buffers and 16 kbytes for receive buffers. Socket allocations are configurable within each direction's total limit. Assigning more memory to a socket leaves less for the others in that direction; it does not increase the total memory or the eight hardware-socket limit. Validate burst handling with the actual host service interval.
No. Hardware offload handles the supported protocol path, but the host still configures the controller, manages sockets, transfers data and implements application behavior. Required services, error recovery and security still need an appropriate software plan. WIZnet's ioLibrary provides a starting point, not proof that the finished application has been validated.
Identify the W5500 IC separately from any Ethernet module. Provide quantity, package/carrier, delivery date and lot/documentation needs, plus the MCU, IPv4 requirement, SPI setup, socket count, buffer allocation and tested traffic target when alternatives are invited. List approved connector/magnetics codes if those parts are also requested, and confirm documentation and checks for the actual offered lot.
Category: Applications & Solutions
By Alice Chen
W5500 is a WIZnet Ethernet controller that adds hardware IPv4 and a 10/100 MAC/PHY to an MCU via SPI. It can be a practical way to keep an existing controller platform, provided the network fits eight hardware sockets and the available host-interface budget. Before ordering, separate the Ethernet link speed from useful application throughput, and decide which network services and software responsibilities remain with the MCU. Those choices define the real network BOM.
WIZnet's W5500 documentation describes a hardwired TCP/IP controller with an integrated MAC and PHY. The host manages sockets and moves application data through SPI instead of implementing the whole hardwired protocol path itself.
The useful economic comparison is between retaining a proven MCU platform plus this network path and changing to a different controller architecture. Include software integration, board changes, connector/magnetics, EMC work and production testing. A low IC price is not enough if the selected host cannot service the required traffic while doing its existing job.
Conversely, replacing the MCU simply because Ethernet is needed can add avoidable development work when a bounded IPv4 application fits the offload approach. Begin with the required services, connections and data patterns, then test the retained platform under that load.
The W5500 datasheet v1.1.0 specifies an SPI frame with a 16-bit address phase, an 8-bit control phase and the data phase. In variable-length data mode, a transaction can transfer multiple sequential bytes while the host controls chip select.
Consider a deliberately simplified calculation at 33.3 MHz SPI. A 64-byte payload transfer carries 67 bytes including the three-byte address/control overhead, so payload transfer efficiency is 64/67, or about 95.5%. Its ideal one-direction payload ceiling from that transaction alone is approximately 31.8 Mbit/s. A one-byte register transaction uses four bytes for one byte of useful data, only 25% by the same accounting.
These are arithmetic illustrations, not WIZnet benchmark results. They exclude status reads, command writes, bus gaps, MCU execution, sharing with other peripherals, TCP behavior and network framing. They explain why burst size and firmware access patterns belong in the design review. Doubling a clock does not remove a slow driver or a host that cannot schedule transfers predictably.
The datasheet's SPI timing footnote adds an important qualification: it calls 80 MHz the theoretical design speed and identifies 33.3 MHz as the tested guaranteed level with stable waveforms. Higher-speed operation therefore needs the actual routing, loading and signal integrity checked.
Specify a measured application target, not “100-Mbps Ethernet performance.”
Figure 1. Transaction arithmetic only: 64/(64 + 3) gives about 95.5% payload share and an ideal 31.8-Mbit/s ceiling at 33.3 MHz before other overheads. TX and RX each have a separate 16-kbyte allocation limit across eight sockets. Not an application benchmark or a fixed socket allocation. State payload size, direction, connection count and permitted latency. Exercise that traffic while the MCU performs its real acquisition, control or display work. If SPI is shared, include the other peripherals rather than benchmarking the Ethernet path alone.
Eight sockets are a finite pool of hardware resources, not a promise of eight unlimited application services. Count simultaneous connections, temporary service sockets and recovery behavior. A product that normally has one data connection may need additional resources during provisioning, name resolution or diagnostics.
The datasheet splits the memory into 16 kbytes for TX and 16 kbytes for RX, with configurable socket allocations. Each direction has its own total allocation limit. A larger buffer for one socket therefore takes capacity from other sockets in the same direction; the “32 kbytes” headline is not 32 kbytes available to every connection.
Table 1. Define the network load that the W5500 board must support
| Requirement | What to record | Procurement/design consequence |
|---|---|---|
| Concurrent connections | Persistent plus temporary socket use | Decide whether eight sockets leave operating headroom |
| Bursty reception | Maximum incoming burst and host service delay | Allocate RX space and validate overflow behavior |
| Outgoing traffic | Payload size and required sustained rate | Check TX allocation and host transfer efficiency |
| Shared SPI | Other devices and scheduling constraints | Verify the actual bus is available when networking needs it |
| Network environment | IPv4, addressing and required application services | Confirm the software plan fits the hardware offload boundary |
Source: WIZnet W5500 datasheet v1.1.0, host-interface and buffer-register sections; examples are planning tasks, not a fixed allocation.
Firmware still owns the application behavior. WIZnet's official ioLibrary driver repository provides chip drivers and application-protocol examples, but selecting a library does not complete recovery, security or the application's own validation. Freeze the approved driver version and host-interface settings with the hardware release.
The W6100 official overview explicitly supports an IPv4/IPv6 dual stack. That makes it a relevant architecture candidate when the planned network cannot remain IPv4-only.
Table 2. Decide IP-stack requirements before comparing W5500 controller prices
| Device | Hardwired IP scope | Decision |
|---|---|---|
| W5500 | IPv4 | Fits an approved IPv4 application with suitable SPI/socket resources |
| W6100 | IPv4 and IPv6 | Evaluate when dual-stack support is a project requirement |
Source: Official WIZnet W5500 and W6100 product documentation.
This is not a W5500-to-W6100 drop-in approval. Pin functions, hardware interface, register behavior, driver selection and board validation must be reviewed. WIZnet's separate compatibility statements for particular modules or other chips do not automatically apply to a bare W5500 board.
If the existing equipment must continue unchanged, keep W5500 as the required item and evaluate a dual-stack redesign separately. This prevents a broader networking roadmap from silently changing an already-qualified production BOM.
The W5500 documentation identifies the chip as a 48-pin LQFP device. A module containing it can also include magnetics, an RJ45 connector and other circuitry, so identify clearly whether the requested item is the IC or a complete module. Comparing those quotations without separating their contents produces a misleading price decision.
For the IC inquiry, provide W5500, quantity, approved package/carrier, delivery date and lot/documentation requirements. Attach the IPv4 decision, MCU platform, SPI clock and sharing arrangement, connection count, TX/RX allocation and tested traffic target. If magnetics or connector parts are included in the sourcing request, identify their approved codes rather than requesting an unspecified “Ethernet set.”
Request a W5500 quote from YG GROUP and state whether alternatives are permitted. Ask for the source and packaging information and relevant inspection scope for the actual offer. Keeping the network assumptions with the RFQ helps purchasing preserve the engineering value of an existing MCU platform instead of buying only a familiar Ethernet label.