W5100 Ethernet Module Library for Proteus: Arduino UDP Node

Hello friends, I hope you all are doing great. Today, I am going to share the W5100 Ethernet Module Library for Proteus. The W5100 module is the classic blue Ethernet board for Arduino projects: a WIZnet W5100 - the chip of the original Arduino Ethernet Shield - with a HanRun RJ45 jack, a regulator and a 2x5 header. It takes the TCP / IP work off the microcontroller, and the Ethernet library of the Arduino IDE drives it. With this library you can wire the module to your UNO in Proteus and run those sketches as they are - DHCP, DNS, servers, clients and UDP.

This is the thirty-first library of our Wi-Fi / Ethernet series and the fourth of its Ethernet group. Its demo is a UDP node: the UNO broadcasts a short "beat" with its address and a reading to the whole network every five seconds, and answers commands that our Laptop WiFi Monitor and Mobile WiFi Monitor send from their UDP terminals - no connections, just packets.

NOTICE: the PANEL pad, the panel and the virtual router are TEP additions; the W5100's raw modes and its interrupts are not simulated (see the limits at the end). The module works with the Arduino Ethernet library. Your feedback is the fuel that keeps us going, so please tell us what you think in the comments below or in the W5100 Ethernet Module board of our forum. And if our free libraries help you, you can buy us a coffee. So, let's get started with the W5100 Ethernet Module Library for Proteus:

What is the W5100 Ethernet Module?

The W5100 Ethernet module is a small board around the WIZnet W5100, a chip with the whole TCP / IP stack inside: the microcontroller writes a few registers and the chip handles the packets. The W5100 keeps four sockets at a time, with 8 KB of send and 8 KB of receive buffer. Around it sit a HanRun RJ45 MagJack (the transformer and the LEDs inside the socket), a 25 MHz crystal and an AMS1117 3.3 V regulator, so the module runs from 5 V. The pins come out on a 2x5 header.

The Pins of the Module

Wire by the names printed beside the pins - makers order the 2x5 header differently. SCLK, MOSI and MISO go to the SPI pins (D13, D11 and D12 on an UNO), SCS to the chip select (D10 unless the sketch names another pin with Ethernet.init()). RST resets the W5100 while it is LOW and may stay free (the module pulls it up). INT stays HIGH - the Ethernet library polls the chip. 5V or 3V3 powers the module, and GND closes the circuit.

W5100 or W5500?

The W5100 is the older chip. Next to the W5500 of our W5500 Ethernet Module Library for Proteus it has half the sockets and half the buffer memory, a slower SPI interface - every register byte takes a 4-byte frame on the bus - and no link register: Ethernet.linkStatus() returns Unknown, so a sketch cannot see whether the cable is in. The Ethernet library finds the chip by itself and uses the same functions for both, so a sketch moves from one module to the other without changes. The same chip sits on the shield of our Arduino Ethernet Shield Library for Proteus.

Features of the W5100 Ethernet Module Library for Proteus

• The module as it looks: the blue board with the HanRun RJ45 jack and its LINK / ACT LEDs, the W5100 in its LQFP-80 and its crystal, the AMS1117 regulator, the red PWR LED and the 2x5 header; every pin named beside its end.
• The real Ethernet library: our W5100 answers the library exactly as the chip does - we ran the Ethernet library 2.0.2 and the demo sketch unchanged against the model on the PC (13 checks) and in Proteus.
• UDP with broadcasts: a packet to 255.255.255.255 reaches every other device on the network, and broadcasts from the others reach the module.
• DHCP or a fixed address, DNS, TCP clients and servers - four sockets, as on the real chip.
• The W5100's limits: Ethernet.linkStatus() is Unknown, as on the real chip.
• The RST and INT pins: a LOW on RST restarts the W5100; INT stays HIGH.
• The cable: pull it with a click on the jack, the CABLE property or the panel; UDP packets sent meanwhile are lost, as on a real network.
• One network for every part: the cable goes to the same virtual router as our Wi-Fi boards and Ethernet shields; the laptop can ping the module.
• Our Laptop and Mobile WiFi Monitors: a laptop and a phone on the same network, with UDP and TCP terminals, a browser and ping - included in the package.
• Our pop-up panel: the phone, the module card, an ETHERNET card, an SPI page with every socket command (a broadcast is marked so) and the RST / INT pins, a Test page, Settings and Help - with our TEP header, not a Windows title bar.
• A compact package: about 2.91 MB, without the C++ source code of the models.

The W5100 Ethernet Module in Proteus

Search W5100 in Pick Devices; the device W5100 ETHERNET MODULE is in TEPW5100MOD.LIB. Click the PANEL pad or the W5100 to open the panel, and the RJ45 jack to pull or plug the cable.

Every State of the W5100 Module

We ran the demo and paused the simulation for each picture. At Run the library tests the chip and asks the router for an address:

Download W5100 Ethernet Module Library for Proteus

Click the button below to download W5100-Ethernet-Module-Library-for-Proteus-v1.0.zip (about 2.91 MB, without the C++ source code of the models):

• README.txt: the device, installation, the demo, the pins, the properties, troubleshooting and the limits.
• Proteus Library Files: TEPW5100MOD.LIB (the module), ArduinoV4TEP.LIB (our Arduino boards V4.0 - the UNO of the demo), TEPLAPTOP.LIB and TEPMOBILE.LIB (our Laptop and Mobile WiFi Monitors).
• Proteus Model Files: TEPNET.DLL (the module, the two monitors and the network) and TEPARDUINO.DLL (the Arduino boards).
• Proteus Simulation: the demo project, its HEX file and copies of the DLLs.
• Arduino Code: the demo sketch. The Ethernet library is not included - it comes with the Arduino IDE.

No Proteus yet? Read How to Download and Install Proteus 7 and 8. New to libraries? Follow How to Install a New Library in Proteus.

How to Install W5100 Ethernet Module Library for Proteus

1. Close Proteus and extract the whole zip file, for example to your Desktop.
2. Copy the four files from Proteus Library Files into the LIBRARY folder of Proteus (usually C:\Program Files (x86)\Labcenter Electronics\Proteus 8 Professional\LIBRARY).
3. Copy TEPNET.DLL and TEPARDUINO.DLL from Proteus Model Files into the MODELS folder - replace older copies (this TEPNET.DLL is the first one that knows the W5100 module, and it still runs our W5500 module, our Ethernet shields, every Wi-Fi part of the series and the two monitors).
4. Delete TEPW5100MOD.IDX, ArduinoV4TEP.IDX, TEPLAPTOP.IDX and TEPMOBILE.IDX from the LIBRARY folder if they are there.
5. Start Proteus, press P and search for W5100.

The sketch is a normal UNO sketch: the Ethernet library is built into the Arduino IDE, so write your sketch and use Sketch > Export Compiled Binary; then double-click the UNO in Proteus and set its Program File to the HEX (see How to get the HEX file from Arduino).

Demo: A UDP Node on Port 4210

Open W5100-UDP-Node-with-Laptop-and-Mobile.pdsprj. On the left is our UNO V4.0 (ARD1, from our Arduino UNO Library for Proteus V4.0) with its built-in serial monitor and a pot on A0, in the middle the W5100 module (U1), and on the right the laptop (PC1) and the phone (MOB1) - no wires to them, they are on the router's network like the real ones.

Four net labels make the SPI connections: SCK, MISO and MOSI from D13, D12 and D11, and ETH_CS from D10 to SCS. The module's 5V goes to VCC and its GND to ground; RST, 3V3 and INT stay free. RV1 (10k, at 35 %) on A0 gives the reading in the beats:

The two tools come from our Laptop WiFi Monitor Library for Proteus and Mobile WiFi Monitor Library for Proteus. In this project both start with their UDP terminal listening on port 4210 and sending to the broadcast address 192.168.1.255:4210; the laptop is 192.168.1.21 and the phone 192.168.1.41:

The Sketch: DHCP and a UDP Socket

The sketch includes the Ethernet library and its UDP class. One port - 4210, the port of our monitors' UDP terminals - and the broadcast address, 255.255.255.255, which every device on the network listens to:

#include <SPI.h>
#include <Ethernet.h>
#include <EthernetUdp.h>

byte mac[] = {0xDE, 0xAD, 0xBE, 0xEF, 0x51, 0x00};
const unsigned int PORT = 4210;            // the UDP port of our Laptop / Mobile WiFi Monitors
IPAddress everyone(255, 255, 255, 255);    // the broadcast address: every device on the network
EthernetUDP udp;

Ethernet.init() names the chip select pin, and Ethernet.begin(mac) asks the router for an address. If no answer comes, Ethernet.hardwareStatus() tells a missing chip from a missing cable:

  Ethernet.init(10);

  if (Ethernet.begin(mac) == 0) {
    Serial.println(Ethernet.hardwareStatus() == EthernetNoHardware ? F(" no W5100 found - check the wiring") : F(" no answer - is the cable in?"));
    while (true) {}
  }

Then the sketch asks for the link. On a W5100 the answer is always Unknown - the chip has no register for it - and the sketch says so:

  EthernetLinkStatus link = Ethernet.linkStatus();
  Serial.println(link == LinkON ? F("ON") : link == LinkOFF ? F("OFF") : F("unknown (the W5100 has no link register)"));

Finally udp.begin() opens a UDP socket on port 4210. Press Run and watch the UNO's monitor:

  udp.begin(PORT);

W5100 UDP Node - The Engineering Projects
DHCP... OK
Chip: W5100
Link status: unknown (the W5100 has no link register)
IP address: 192.168.1.101
UDP on port 4210 - beats to everyone every 5 s; commands: PING, A0, RATE, STOP, START, STATUS, HELP

A Beat to Everyone

Why UDP? TCP, which our other Ethernet demos use, opens a connection, numbers every byte and sends again whatever gets lost. UDP just sends single packets: there is no connection to open, one packet can go to every device at once, and nothing is sent twice. That suits status beats, sensor readings and "who is on the network?" questions, where the next packet replaces a lost one - and it keeps the sketch small.

Every five seconds loop() calls beat(), which reads A0 and sends one line to the broadcast address. A UDP packet is built between beginPacket() and endPacket() - no connection, no answer expected:

  if (beating && millis() - lastBeat >= rate) beat();

  snprintf_P(reply, sizeof reply, PSTR("NODE %s: A0=%d (%s V) beat %u"), ip, a0, v, beats);
  sendTo(everyone, PORT, reply);

void sendTo(IPAddress to, unsigned int port, const char *text) {
  udp.beginPacket(to, port);
  udp.write((const uint8_t *)text, strlen(text));
  udp.endPacket();
}

Open the Terminal of the laptop and of the phone - both listen on port 4210, so both hear every beat:

NODE 192.168.1.101: A0=358 (1.75 V) beat 1
NODE 192.168.1.101: A0=358 (1.75 V) beat 2
NODE 192.168.1.101: A0=358 (1.75 V) beat 3

Commands by UDP

Each time round, receive() asks udp.parsePacket() whether a packet came in. It reads the text, drops the CR LF the terminals add, and remembers who sent it:

  int size = udp.parsePacket();
  if (!size) return;

  while (n > 0 && (packet[n - 1] == '\r' || packet[n - 1] == '\n' || packet[n - 1] == ' ')) n--;   // the terminals add CR LF

  IPAddress from = udp.remoteIP();
  unsigned int port = udp.remotePort();

The answer goes back to that address and port only - not to everyone:

  sendTo(from, port, reply);               // the answer: to the sender only

Type PING, A0 and STATUS in the laptop's terminal and press Send. The laptop sends to the broadcast address, the node answers the laptop:

From 192.168.1.21:4210: PING
  answer: PONG from 192.168.1.101
Beat 4 sent to everyone
From 192.168.1.21:4210: A0
  answer: A0=358 (1.75 V)
From 192.168.1.21:4210: STATUS
  answer: IP 192.168.1.101, beats 4 every 5 s, received 3

RATE, STOP and START

RATE changes the beat interval, STOP and START pause and resume the beats; START sends one at once:

  } else if (!strncmp(cmd, "RATE ", 5)) {
    int s = atoi(cmd + 5);
    if (s >= 1 && s <= 60) { rate = s * 1000UL; snprintf_P(reply, sizeof reply, PSTR("beats every %d s"), s); }
    else strcpy_P(reply, PSTR("RATE takes 1 to 60 (seconds)"));

  } else if (!strcmp(cmd, "START")) {
    beating = true;
    lastBeat = millis() - rate;            // the next beat at once
    strcpy_P(reply, PSTR("beats started"));

RATE 2
beats every 2 s
NODE 192.168.1.101: A0=358 (1.75 V) beat 5
STOP
beats stopped
START
beats started
NODE 192.168.1.101: A0=358 (1.75 V) beat 6
RATE 5
beats every 5 s

The phone hears the laptop's commands too - they went to the broadcast address - but not the answers. When the phone itself sends HELP, the list comes back to the phone only. The UNO's monitor takes STATUS and HELP as well, and broadcasts any other line it gets as "UNO: ..." - here the phone shows it:

      snprintf_P(reply, sizeof reply, PSTR("UNO: %s"), line);
      sendTo(everyone, PORT, reply);

STATUS
IP 192.168.1.101, beats 6 every 5 s, received 8
HELP
PING, A0, RATE <s>, STOP, START, STATUS, HELP
Hello from the UNO
Sent to everyone: UNO: Hello from the UNO

loop() also calls Ethernet.maintain(), which renews the DHCP lease when it is due:

  Ethernet.maintain();                     // renews the DHCP lease when it is due

Ping and the Cable Test

The laptop's Network tab lists the module and pings it:

Then the panel's cable test pulls the cable for 3 seconds, three times. The sketch keeps sending its beats - it cannot know: the W5100 has no link register. Beats 8, 9 and 10 fell into the three pulls; the monitor shows them sent, but the laptop never got them. UDP has no retries - a packet that finds no cable is simply lost:

Beat 7 sent to everyone
Beat 8 sent to everyone
Beat 9 sent to everyone
Beat 10 sent to everyone

And the whole demo running:

The W5100 Ethernet Module Panel

The panel opens at Run, in the look of our TEP Serial Monitor Advance for Proteus - our own TEP header, no Windows title bar. Its first page has a small phone of its own with the CABLE IN and CABLE OUT buttons, and three cards: MODULE with the chip, the MAC address, the host link and the LEDs, ETHERNET with the router, the status, the address with its gateway and mask and the DHCP time, and TRAFFIC:

The SPI page lists what the Ethernet library asks the W5100, newest first. A beat is one SEND to 255.255.255.255:4210, marked as a broadcast; each command is a RECV and a SEND back to its sender. The card at the bottom shows the RST and INT pins:

The ROUTER tab lists the router's clients, the module among them as a LAN client:

The Test page measures the running model. Its web request test needs a sketch with a web server, so it stays empty here; the cable test pulls the cable for 3 seconds three times:

The footer counts the register accesses - the library reads the socket status all the time, about 49,000 register reads a second while it waits.

Pins of the W5100 Ethernet Module

Properties of the W5100 Ethernet Module

With DHCP the address follows the part's number: U1 gets 192.168.1.101, U2 .102 and so on. The laptop is always 192.168.1.21 and the phone 192.168.1.41.

Troubleshooting

• Ethernet.begin() returns 0 and the hardware status is EthernetNoHardware: check SCLK, MISO, MOSI, SCS (and Ethernet.init() when it is not D10), the power and GND, and that RST is not held LOW.
• DHCP never answers: the cable is out - put it in with the panel, or click the RJ45 jack. The sketch cannot see it: linkStatus() is Unknown on a W5100.
• A terminal hears nothing: its UDP port must be the sketch's (4210) - the terminal's Local port box.
• An answer goes to the wrong terminal: answers go to udp.remoteIP() and udp.remotePort() - the sender of that packet.
• No panel: click the PANEL pad or the W5100, or turn "Open the panel at Run" back on in Settings.

Things to Know Before Using a Real W5100 Module

• Power: feed the module's 5V pin (its AMS1117 makes the 3.3 V) rather than a weak 3.3 V pin.
• The header: makers order the 2x5 pins differently - always wire by the names printed on your board.
• The MAC address: the module has none of its own; give each module on the network a different one in the sketch.
• Broadcasts: 255.255.255.255 reaches your own network only - routers do not pass it on. Some networks also block broadcasts between Wi-Fi and wired devices.
• UDP is unreliable by design: packets can be lost or come twice; number them, as the beats do, when it matters.
• The size of the sketch: the demo takes 19,150 of the UNO's 32,256 bytes of flash and 748 of its 2,048 bytes of RAM.

Limitations of the Simulation

• The W5100 is our model of the chip as the Ethernet library (2.0) uses it - the registers, the sockets and the buffers - not a packet-level simulation of Ethernet.
• Not modelled: IPRAW and MACRAW traffic (the modes open but carry nothing), PPPoE, the socket interrupts (INT stays HIGH), the PHY's auto-negotiation (it is always 100 Mbit/s full duplex), the supply's voltage and current. A ping is always answered.
• With the cable out the TCP connections are kept for 20 s - our choice, close to what a real network does for a short pull; UDP packets sent meanwhile are lost.
• The PANEL pad, the panel, its phone, the router, the internet host and the two monitors are TEP additions.
• W5100 is a name of WIZnet; this library is not made or endorsed by WIZnet or Labcenter.
• Tested in Proteus 8.5 in October 2026 (the demo as shipped, the UNO, the module, the laptop and the phone together at about 0.12 to 0.15 x real time on our PC). Proteus 7 is not supported.

So, that was all about the W5100 Ethernet Module Library for Proteus. I hope it helps you try UDP on a wired network in Proteus - broadcasts, commands and answers - and the other Ethernet library sketches on the classic W5100, while you watch every socket command on the panel. The cable goes to the same router as our Wi-Fi boards, so a wired UNO and a Wi-Fi ESP32 can share one design. If you use the W5100 Ethernet Module Library for Proteus in a project, please share it in the comments or in our forum, and if you have any questions, ask in the comments and I will help you out. Till the next tutorial, take care and have fun!