The W5500 chip is a Hardwired Internet controller designed as a full hardwired TCP/IP stack with WIZnet technology. W5500 provides Internet connectivity to your embedded systems by using SPI(Serial Peripheral Interface). SPI provides easy connection via external MCU to W5500. The clock speed of W5500 SPI supports upto 80MHz.
Since W5500 integrates the Hardwired TCP/IP stack with 10/100 Ethernet MAC and PHY, it is truly a one-chip solution for the stable internet connectivity. WIZnet's Hardwired TCP/IP stack supports TCP, UDP, IPv4, ICMP, ARP, IGMP, and PPPoE - and it has been proven through various applications over the last decade.
W5500 provides 8 independent SOCKETs to be used simultaneously and 32KB internal memory for data communication. Users can develop an Ethernet application easily by using the simple W5500 SOCKET program instead of handling a complex Ethernet controller. W5500 also provides WOL (Wake on LAN) and a Power Down Mode in order to reduce power consumption.
Version | Date | Description |
---|---|---|
1.0.0 | 2013-08-01 | Initial Release |
1.0.1 | 2013-09-13 | Corrected duplicated statements and typing errors (P.14, 23, 24, 28, 39, 51) Corrected descriptions (P.35) |
1.0.2 | 2013-11-14 | Changed “descriptions of pin at 1.1 Pin Descriptions” (P.10) starting ”It must be tied to GND to NC (PIN38..42)” / 2. corrected typing error: starting “0x02 to 0x42 value of SOCK_MACRAW at 4.2 Socket Registers(P.50)” |
1.0.3 | 2014-05-29 | Corrected “Sn_MSSR at 4.2 Socket Register” (P.53): wrong descriptions of Sn_MSSR about FMTU/MTU |
1.0.4 | 2014-06-13 | 1. Added Note about reading size register value (P.56, 58) / 2. Added IR Reflow Temperature Profile (P.66) |
1.0.5 | 2014-11-11 | 1. Added description for MISO pin (P.11):The SCSn signal defines MISO pin output value / 2. Modified the register notation (P.33), Modified the register notation “Sn_IR at 4.2 Socket Register” (P.49) :from [R] to [RCW1] / 3. Corrected typing error: from DICON to DISCON of Sn_SR at 4.2 Socket Register (P.50) |
1.0.6 | 2014-12-30 | Corrected typing error : from 0x02 to 0x42 value of SOCK_MACRAW “Sn_CR at 4.2 Socket Registers”(P.46) |
1.0.7 | 2016-02-24 | 1. Corrected Interrupt Assert Wait Time function (P.34) / 2. Notice PLLclk is 150MHz (P.34) |
1.0.8 | 2017-05-19 | 1. Corrected Driver Level Range Unit uW/MHz to uW (P.60) |
1.0.9 | 2019-05-22 | 1. Corrected Sn_IMR Description (P.55) 2. Corrected Junction temperature Min value TJ (P.57) 3. Added Maximum junction temperature TJMAX (P.58) |
Version | Date | Description |
---|---|---|
1.0 | 2013-08-01 | Initial Release |
1.1 | 2014-01-17 | Changed “External Transformer + RJ-45 to MAGJACK(inside transformer)” |
1.2 | 2015-04-20 | Added “Resistor 33R in MDI line. because EMI issue.” Changed “PCB artwork. because changed develop tool(PADS → Altium) ” |
1.3 | 2018-08-10 | Modified “inner 2 layer copper foil (3V3D). This copper foil plated below of CHAND area. It may affect ESD.” |
The ioLibrary means “Internet Offload Library” for WIZnet chip. It includes drivers and application protocols. There are three kinds of libraries explained on this page The first two drivers (ioLibrary_BSD, ioLibrary) can be used for W5500 application designs. These will be updated continuously. The former BSD-Type driver will not be updated, as it is only meant to be a migration help from W5200 to W5500.
1. ioLibrary_BSD
2. ioLibrary
3. BSD Type driver for W5200 User
This driver provides the Berkeley Socket type APIs. The function names of this ioLibrary_BSD are the same as the function names of the ioLibrary.
< ioLibrary_BSD : latest version >
ioLibrary_BSD GitHub Repository
< ioLibrary_BSD : old version >
Type | Version | Note | Download Link | |
---|---|---|---|---|
Source code | Ethernet (Berkeley Socket type APIs) | 1.0.3 | - | Click |
1.0.2 | - | Click | ||
1.0.1 | - | Click | ||
1.0.0 | - | Click | ||
Internet (Application protocols) | 1.1.1 | - | Click | |
1.1.0 | - | Click | ||
1.0.0 | - | Click | ||
Documents | Socket APIs Help (chm, html) | 1.0.3 | - | Click |
1.0.2 | - | Click | ||
1.0.1 | - | Click | ||
1.0.0 | - | Click |
< Update History >
< Application code examples : latest version >
Application | Update | Note | Download Link | |
---|---|---|---|---|
STM32F103X CooCox CoIDE Project | Loopback Test | 2013-11-04 | - | Click |
DHCP Client | 2013-12-26 | - | Click | |
DNS Client | 2013-12-26 | - | Click | |
EnergyMicro Tiny GECKO(EFM32TG840F32) IAR Project | Loopback Test DHCP Client DNS Client | 2013-12-20 | - | Click |
< Application code examples : old version >
Application | Update | Note | Download Link | |
---|---|---|---|---|
STM32F103X CooCox CoIDE Project | Loopback Test | 2013-10-23 | - | Click |
DHCP Client | 2013-11-08 | - | Click | |
DNS Client | 2013-11-08 | - | Click |
These projects do not contain [Ethernet] and [Internet] codes. (Empty directory)
Please download ioLibrary_BSD APIs and Application protocols,
and then insert to each of same named directory in provided project.
< History >
This driver provides BSD-type Socket APIs for W5500. Because the function names of this driver are more user-friendly than those of the older drivers, …, current WIZnet chip users can easily migrate from their WIZnet chip application to the W5500 application. All drivers for W5100, W5200 and W5300 will be merged into the ioLibrary in the near future. All application protocols will also be merged into ioLibrary based on this BSD-type Socket APIs.
This table shows the differences between other BSD drivers and new W5500 driver.
Driver | Other BSD Drivers | W5500 Driver |
---|---|---|
Variables Type | type.h (made by wiznet) ex) uint16 | stdint.h (standard) ex) uint16_t |
Register Naming | REGName + Index ex) SIPR0 , SIPR1, SIPR2, SIPR3 | REGName & WIZCHIP_OFFSET_INC ex> SIP, WIZCHIP_OFFSET_INC(SIP,1), WIZCHIP_OFFSET_INC(SIP,2), WIZCHIP_OFFSET_INC(SIP,3) |
Basic IO function | IINCHIP_READ IINCHIP_WRITE IINCHIP_READ_BUF IINCHIP_WRITE_BUF 16bit Address Space User should implement Functions MCU Dependent | WIZCHIP_READ WIZCHIP_WRITE WIZCHIP_READ_BUF WIZCHIP_WRITE_BUF 32bit Address Space Since users implement MCU-dependent parts and then register them as Callback function, users don't need to implement the Function itself. Supports IINCHIP_XXX function for backward compatiblity. |
Register Function | IINCHIP_XXX can be used. Supports some getREG() & setREG() functions. | It is not recommended to use WIZCHIP_XXXX. Supports getREG() & setREG() functions or macros for all registers. |
Extra Functions | None | Optional and omissible Supports User-friendly named functions. All extra functions can be implemented by using setREG() & getREG(). |
Socket APIs | Other BSD Drivers | W5500 Driver |
---|---|---|
Return Value | void Success or Fail Transmit/Receive Size | Success or Fail Transmit/Receive Size All functions return. |
Error Code | None | SOCK_BUSY : 0 SOCKERR_SOCKNUM SOCKERR_SOCKOPT SOCKERR_SOCKINIT SOCKERR_SOCKCLOSED SOCKERR_SOCKMODE SOCKERR_SOCKFLAG SOCKERR_SOCKSTATUS SOCKERR_ARG SOCKERR_PORTZERO SOCKERR_IPINVALID SOCKERR_TIMEOUT SOCKERR_DATALEN SOCKERR_BUFFER SOCKFATAL_PACKLEN |
IO Mode | Block & Non-Block Fixed | Block or Non-Block configurable |
Block Function | send recv sendto recvfrom | send recv sendto recvfrom connect |
Non-Block Function | connect | |
recvfrom | Should read data in received packet unit. | Can read data received packet separately. |
< ioLibrary with example project : latest version >
Application | Version | Note | Download Link | |
---|---|---|---|---|
Cookie board | Loopback test | 1.0.2 | - | Click |
<Revision History>
< ioLibrary : latest version >
Description | Version | Note | Download Link | |
---|---|---|---|---|
Driver Source code | ioLibrary source code | 1.0.2 | - | Click |
< ioLibrary : old version >
Description | Version | Note | Download Link | |
---|---|---|---|---|
Driver Source code | ioLibrary source code | 1.0.0 | - | Click |
Driver documents | Socket APIs Help(chm, html) (To use html, open the index.html) | 1.0.0 | - | Click |
This ioLibrary has basic I/O functions, socket register access functions, common register access functions, utilities and functions for setting up a platform and network This code has been evaluated on the CooCox Cookie Board with ARM Cortex-M0 MCU.
Please refer to this link for more details.
The figure below shows the folder structure of this ioLibrary.
This driver has the same BSD as the API for W5200 users. We have been evaluating this code on the ARM-CortexM3(STM32F103 series) chipset.
This type of driver is the final version. We will not update it later.
Please use the new (well coded ) driver code for new projects.
For using connected CT signals inside the Transformer or inside RJ45 the matching network (2x 50R) of the RX+/- signals must be isolated from CT (3.3V). For that isolation we need C23 and C24.
Please refer to the following schematic:
The RJ45 from UDE (RB1-125BAG1A) is used in many of our W5100 and W7100A related Modules.
- J1B121ZCCD from CETUS datasheet
- J1B1211CCD from CETUS (used in *1) datasheet
- RB1-1D5B8K1A from UDE datasheet
- RB1-125BAG1A from UDE (used in *2) datasheet
- J0011D21BNL from Pulse datasheet
*1) we use the J1B1211CCD from CETUS in our W5500-EVB, WIZ550io, WIZ550S2E and WIZ550web Modules.
*2) we use the RB1-125BAG1A from UDE in most of our our W5100 & W7100A related Plug-In and Serial-to-Ethernet (S2E) Modules.
By setting some register and memory operation, W5500 provides internet connectivity. This chapter describes how it can be operated.
You must check PHY LINK (0 bit of PHYCFGR) before attempting to make a network connection using sockets.
For the W5500 operation, select and utilize appropriate registers shown below.
For more information of above registers, refer to the “Register Descriptions.”
Basic network information setting for communication: It must be set the basic network information.
This stage sets the socket tx/rx memory information. The base address and mask address of each socket are fixed and saved in this stage.
In case of, assign 2KB rx, tx memroy per SOCKET
In case of, assign 2KB rx, tx memory per SOCKET { Sn_RXMEM_SIZE(ch) = (uint8 *) 2; // Assign 2K rx memory per SOCKET Sn_TXMEM_SIZE(ch) = (uint8 *) 2; // Assign 2K rx memory per SOCKET /* Same method, set gS1_TX_BASE, gS1_TX_MASK, gS2_TX_BASE, gS2_TX_MASK, gS3_TX_BASE, gS3_TX_MASK, gS4_TX_BASE, gS4_TX_MASK, gS5_TX_BASE, gS5_TX_MASK, gS6_TX_BASE, gS6_tx_MASK, gS7_TX_BASE, gS7_TX_MASK */ }
After the initialization process, W5500 can transmit and receive the data with others by ‘open’ the SOCKET of TCP, UDP, IPRAW, and MACRAW mode. The W5500 supports the independently and simultaneously usable 8 SOCKETS. In this section, the communication method for each mode will be introduced.
The TCP is a connection-oriented protocol. The TCP make the connection SOCKET by using its own IP address, port number and destination IP address, port number. Then transmits and receives the data by using this SOCKET. Methods of making the connection to SOCKET are “TCP SERVER” and “TCP CLIENT”. It is divided by transmitting the connect-request (SYN packet). The “TCP SERVER” listens to the connect-request from the “TCP CLIENT”, and makes connection SOCKET by accepting the transmitted connect-request (Passive-open). The “TCP CLIENT” transmits the connect-request first to “TCP SERVER” to make the connection (Active-open).
SOCKET initialization is required for TCP data communication. The initialization is opening the SOCKET. The SOCKET opening process selects one SOCKET from 8 SOCKETS of the W5500, and sets the protocol mode (Sn_MR) and Sn_PORT0 which is source port number (Listen port number in “TCP SERVER”) in the selected SOCKET, and then executes OPEN command. After the OPEN command, if the status of Sn_SR is changed to SOCK_INIT, the SOCKET initialization process is completed. The SOCKET initialization process is identically applied in “TCP SERVER” and “TCP CLIENT.”The Initialization process of Socket n in TCP mode is shown below.
{ START: Sn_MR = 0x01; // sets TCP mode Sn_PORT0 = source_port; // sets source port number Sn_CR = OPEN; // sets OPEN command /* wait until Sn_SR is changed to SOCK_INIT */ if (Sn_SR != SOCK_INIT) Sn_CR = CLOSE; goto START; }
After W5500 accepts the command, the Sn_CR register is automatically cleared to 0x00. Even though Sn_CR is cleared to 0x00, the command is still being processed. To check whether the command is completed or not, please check the Sn_IR or Sn_SR.
Run as “TCP SERVER” by LISTEN command.
{ /* listen SOCKET */ Sn_CR = LISTEN; /* wait until Sn_SR is changed to SOCK_LISTEN */ if (Sn_SR != SOCK_LISTEN) Sn_CR = CLOSE; goto START; }
When the status of Sn_SR is SOCK_LISTEN, if it receives a SYN packet, the status of Sn_SR is changed to SOCK_SYNRECV and transmits the SYN/ACK packet. After that, the Socket n makes a connection. After it makes the connection of Socket n , it enables the data communication. There are two methods to confirm the connection of Socket n .
First method : { if (Sn_IR(CON) == ‘1’) /* When an interrupt occurs and the mask bit of Sn_IMR is ‘1’, the interrupt bit of Sn_IR becomes ‘1’ */ Sn_IR(CON) = ‘1’; /*In order to clear the Sn_IR bit, the host should write the bit as ‘1’. When all the bits of Sn_IR is cleared (‘0’), IR(n) is automatically cleared.*/ goto ESTABLISHED stage; /* In this case, if the interrupt of Socket n is activated, interrupt occurs. Refer to IR, IMR Sn_IMR and Sn_IR. */ } Second method : { if (Sn_SR == SOCK_ESTABLISHED) goto ESTABLISHED stage; }
Confirm the reception of the TCP data.
First method : { if (Sn_IR(RECV) == ‘1’) Sn_IR(RECV) = ‘1’; goto Receiving Process stage; /* In this case, if the interrupt of Socket n is activated, interrupt occurs. Refer to IR, IMR Sn_IMR and Sn_IR. */ } Second Method : { if (Sn_RX_RSR0 != 0x0000) goto Receiving Process stage; }
The First method: set the Sn_IR(RECV) to ‘1’ whenever you receive a DATA packet. If the host receives the next DATA packet without setting the Sn_IR(RECV) as ‘1’ in the prior DATA packet, it cannot recognize the Sn_IR(RECV) of the next DATA packet. This is due to the prior Sn_IR(RECV) and next Sn_IR(RECV) being overlapped. So this method is not recommended if the host cannot perfectly process the DATA packets of each Sn_IR(RECV).
In this process, it processes the TCP data which was received in the Internal RX memory. At the TCP mode, the W5500 cannot receive the data if the size of received data is larger than the RX memory free size of Socket n . If the prior stated condition is happened, the W5500 holds on to the connection (pauses), and waits until the RX memory’s free size is larger than the size of the received data.
{ /* first, get the received size */ len = Sn_RX_RSR; // len is received size /* select RX memory, refer to Datasheet 14 page */ cntl_byte = Socket_n_RX_Buffer /* Get offset address */ src_ptr = Sn_RX_RD; /* set memory copy len bytes of source_ptr to destination_address */ for (i=0; i<len; i++) { *(dst_ptr+i) = W5500_READ(addr, cntl_byte, src_ptr+i); } /* increase Sn_RX_RD as length of len */ Sn_RX_RD += len; /* set RECV command */ Sn_CR = RECV; }
The size of the transmit data cannot be larger than assigned internal TX memory of Socket n. If the size of transmit data is larger than configured MSS, it is divided by size of MSS and transmits. To transmit the next data, user must check the completion of prior SEND command. An error may occur if the SEND command executes before completion of prior SEND command. The larger the data size, the more time to complete the SEND command. So the user should properly divide the data to transmit.
To check the completion of the SEND command, it should be check that the send data length is equal with the actual sent data length. The actual sent data length is calculated by the difference of the Sn_TX_RD before and after performing the SEND command. If the actual sent data is less than the send data length, the SEND command is retried for sending the left data. The send process is therefore completed the SENDwhen the sum of the actual sent data is equal the send data length. A simple example of the send process is as below
Ex) Send Data Length Size= 10,
Note: Don’t copy data until the sum of the actual sent data length is the send data length.
{ /* first, get the free TX memory size */ FREESIZE: freesize = Sn_TX_FSR; if (freesize<len) goto FREESIZE; // len is send size /* select TX memory, refer to Datasheet 14 page */ cntl_byte = Socket_n_TX_Buffer /* Get offset address */ dst_ptr = Sn_TX_RD; /* set memory copy len bytes of source_ptr to destination_address */ for (i=0; i<len; i++) { W5500_WRITE(addr, cntl_byte, dst_ptr+i); } /* increase Sn_TX_WR as length of len */ Sn_TX_WR += send_size; /* set SEND command */ Sn_CR = SEND; /* return real packet size */ return len; }
Check if the Disconnect-request(FIN packet) has been received. User can confirm the reception of FIN packet as below.
First method : { if (Sn_IR(DISCON) == ‘1’) Sn_IR(DISCON)=‘1’; goto CLOSED stage; /* In this case, if the interrupt of Socket n is activated, interrupt occurs. Refer to IR, IMR Sn_IMR and Sn_IR. */ } Second method : { if (Sn_SR == SOCK_CLOSE_WAIT) goto CLOSED stage; }
When the user does not need data communication with others, or receives a FIN packet, disconnect the connection SOCKET.
{ /* set DISCON command */ Sn_CR = DISCON; }
Confirm that the Socket n is disconnected or closed by DISCON or close command.
First method : { if (Sn_IR(DISCON) == ‘1’) goto CLOSED stage; /* In this case, if the interrupt of Socket n is activated, interrupt occurs. Refer to IR, IMR Sn_IMR and Sn_IR. */ } Second method : { if (Sn_SR == SOCK_CLOSED) goto CLOSED stage; }
The timeout can occur by Connect-request(SYN packet) or its response(SYN/ACK packet), the DATA packet or its response(DATA/ACK packet), the Disconnectrequest FIN packet) or its response(FIN/ACK packet) and transmission all TCP packet. If it cannot transmit the above packets within ‘timeout’ which is configured at RTR and RCR, the TCP final timeout(TCPTO) occurs and the state of Sn_SR is set to SOCK_CLOSED. Confirming method of the TCPTO is as below:
First method : { if (Sn_IR(TIMEOUT bit) == ‘1’) Sn_IR(TIMEOUT)=‘1’; goto CLOSED stage; /* In this case, if the interrupt of Socket n is activated, interrupt occurs. Refer to IR, IMR Sn_IMR and Sn_IR. */ } Second method : { if (Sn_SR == SOCK_CLOSED) goto CLOSED stage; }
It can be used to close the Socket n , which disconnected by disconnect-process, or closed by TCPTO or closed by host’s need without disconnect-process.
{ /* clear the remained interrupts of Socket n */ Sn_IR = 0xFF; IR(n) = ‘1’; /* set CLOSE command */ Sn_CR = CLOSE; }
Transmit the connect-request (SYN packet) to “TCP SERVER”. It may occurs the timeout such as ARPTO, TCPTO when make the “connection SOCKET” with “TCP SERVER”
{ Sn_DIPR0 = server_ip; /* set TCP SERVER IP address*/ Sn_DPORT0 = server_port; /* set TCP SERVER listen port number*/ Sn_CR = CONNECT; /* set CONNECT command */ }
By setting some register and memory operation, W5500 provides internet connectivity. This chapter describes how it can be operated.
You must check PHY LINK (0 bit of PHYCFGR) before attempting to make a network connection using sockets.
For the W5500 operation, select and utilize appropriate registers shown below.
For more information of above registers, refer to the “Register Descriptions.”
Basic network information setting for communication: It must be set the basic network information.
This stage sets the socket tx/rx memory information. The base address and mask address of each socket are fixed and saved in this stage.
In case of, assign 2KB rx, tx memroy per SOCKET
In case of, assign 2KB rx, tx memory per SOCKET { Sn_RXMEM_SIZE(ch) = (uint8 *) 2; // Assign 2K rx memory per SOCKET Sn_TXMEM_SIZE(ch) = (uint8 *) 2; // Assign 2K rx memory per SOCKET /* Same method, set gS1_TX_BASE, gS1_TX_MASK, gS2_TX_BASE, gS2_TX_MASK, gS3_TX_BASE, gS3_TX_MASK, gS4_TX_BASE, gS4_TX_MASK, gS5_TX_BASE, gS5_TX_MASK, gS6_TX_BASE, gS6_tx_MASK, gS7_TX_BASE, gS7_TX_MASK */ }
After the initialization process, W5500 can transmit and receive the data with others by ‘open’ the SOCKET of TCP, UDP, IPRAW, and MACRAW mode. The W5500 supports the independently and simultaneously usable 8 SOCKETS. In this section, the communication method for each mode will be introduced.
The UDP is a Connection-less protocol. It communicates without “connection SOCKET.” The TCP protocol guarantees reliable data communication, but the UDP protocol uses datagram communication which has no guarantees of data communication. Because the UDP does not use “connection SOCKET,” it can communicate with many other devices with the known host IP address and port number. This is a great advantage; communication with many others by using just one SOCKET, but also it has many problems such as loss of transmitted data, unwanted data received from others, etc. To avoid these problems and guarantee reliability, the host retransmits damaged data or ignores the unwanted data which is received from others. The UDP protocol supports unicast, broadcast, and multicast communication. It follows the below communication flow.
The unicast is one method of UDP communication. It transmits data to one destination at one time. On the other hand, the broadcast communication transmits data to all receivable destinations by using ‘broadcast IP address (255.255.255.255)’. For example, suppose that the user transmits data to destination A, B, and C. The unicast communication transmits each destination A, B, and C at each time. At this time, the ARPTO can also occur when the user gets the destination hardware address of destinations A, B and C. User cannot transmit data to destinations which have ARPTO. The broadcast communication can simultaneously transmit data to destination A, B and C at one time by using “255.255.255.255” or “local address | (~subnet address)” IP address. At this time, there is no need to get the destination hardware address about destination A, B and C, and also ARPTOis not occurred.
⇒ The Broadcast IP address can be obtained by performing a bit-wise logical OR operation between the bit complement of the subnet mask and the host’s IP address.
ex> If IP:”222.98.173.123” and the subnet mask:“255.255.255.0”, broadcast IP is “222.98.173.255”
Description | Decimal | Binary |
---|---|---|
HOST IP | 222.098.173.123 | 11011110.01100010.10101101.01111011 |
Bit Complement Subnet mask | 000.000.000.255 | 00000000.00000000.00000000.11111111 |
Bitwise OR | - | - |
Broadcast IP | 222.098.173.255 | 11011110.01100010.10101101.11111111 |
For the UDP data communication, SOCKET initialization is required; it opens the SOCKET. The SOCKET open process is as followed. At first, choose one SOCKET among the 8 SOCKETS of W5500, then set the protocol mode (Sn_MR(P3:P0)) of the chosen SOCKET and set the source port number Sn_PORT0 for communication. Finally, execute the OPEN command. After the OPEN command, the state of Sn_SR is changed to SOCK_UDP. Then the SOCKET initialization is complete.
{ START: Sn_MR = 0x02; /* sets UDP mode */ Sn_PORT0 = source_port; /* sets source port number */ Sn_CR = OPEN; /* sets OPEN command */ /* wait until Sn_SR is changed to SOCK_UDP */ if (Sn_SR != SOCK_UDP) Sn_CR = CLOSE; goto START; }
After W5500 accepts the command, the Sn_CR register is automatically cleared to 0x00. Even though Sn_CR is cleared to 0x00, the command is still being processed. To check whether the command is completed or not, please check the Sn_IR or Sn_SR.
Check the reception of UDP data from destination. User can also check for received data via TCP communication. It is strongly recommended to use the second method because of the same reasoning from TCP. Please refer to the “TCP SERVER” section. TCP SERVER
First method : { if (Sn_IR(RECV) == ‘1’) Sn_IR(RECV) = ‘1’; goto Receiving Process stage; /* In this case, if the interrupt of Socket n is activated, interrupt occurs. Refer to IR, IMR Sn_IMR and Sn_IR. */ } Second Method : { if (Sn_RX_RSR0 != 0x0000) goto Receiving Process stage; }
Process the received UDP data in Internal RX memory.
The structure of received UDP data is as below.
The received UDP data consists of 8bytes PACKET-INFO, and DATA packet. The PACKETINFO contains transmitter’s information (IP address, Port number) and the length of DATA packet. The UDP can receive UDP data from many others. User can classify the transmitter by transmitter’s information of PACKET-INFO. It also receives broadcast SOCKET by using “255.255.255.255” IP address. So the host should ignore unwanted reception by analysis of transmitter’s information. If the DATA size of Socket n is larger than Internal RX memory free size, user cannot receive that DATA and also cannot receive fragmented DATA.
{ /* Get offset address */ src_ptr = Sn_RX_RD; /* select RX memory, refer to Datasheet 14 page */ cntl_byte = Socket_n_RX_Buffer /* read head information (8 bytes) */ header_size = 8; /* copy header_size bytes of get_start_address to header_address */ for(i=0; i<header_size; i++) { header[i] = W5500_READ(src_ptr, header); } /* update src_ptr */ src_ptr += header_size; /* save remote peer information & received data size */ peer_ip = header[0 to 3]; peer_port = header[4 to 5]; get_size = header[6 to 7]; /* copy len bytes of src_ptr to destination_address */ for(i=0; i<get_size; i++) { *(dst_ptr+i) = W5500_READ(addr, cntl_byte, src_ptr+1); } /* increase Sn_RX_RD as length of len+ header_size */ Sn_RX_RD += get_size; /* set RECV command */ Sn_CR = RECV; }
The size of DATA that the user wants to transmit cannot be larger than Internal TX memory. If it is larger than MTU, it is automatically divided by MTU unit and transmitted. The Sn_DIPR0 is set “255.255.255.255” when user wants to broadcast.
{ /* first, get the free TX memory size */ FREESIZE: freesize = Sn_TX_FSR0; if (freesize<len) goto FREESIZE; // len is send size /* Write the value of remote_ip, remote_port to the Socket n Destination IP Address Register(Sn_DIPR), Socket n Destination Port Register(Sn_DPORT). */ Sn_DIPR0 = remote_ip; Sn_DPORT0 = remote_port; /* Get offset address */ dst_ptr = Sn_TX_WR; /* select TX memory, refer to Datasheet 14 page */ cntl_byte = Socket_n_TX_Buffer /* copy len bytes of source_address to dst_ptr */ for(i=0; i<len; i++) { W5500_WRITE(addr, cntl_byte, dst_ptr+i); } /* increase Sn_TX_WR0 as length of len */ Sn_TX_WR += len; /* set SEND command */ Sn_CR = SEND; }
To transmit the next data, user must check that the prior SEND command is completed. The larger the data size, the more time to complete the SEND command. Therefore, the user must properly divide the data to transmit. The ARPTO can occur when user transmits UDP data. If ARPTO occurs, the UDP data transmission has failed.
First method : { /* check SEND command completion */ while(Sn_IR(SENDOK)==‘0’) /* wait interrupt of SEND completion */ { /* check ARPTO */ if (Sn_IR(TIMEOUT)==‘1’) Sn_IR(TIMEOUT)=‘1’; goto Next stage; } Sn_IR(SENDOK) = ‘1’; /* clear previous interrupt of SEND completion */ } Second method : { If (Sn_CR == 0x00) transmission is completed. If (Sn_IR(TIMEOUT bit) == ‘1’) goto next stage; /* In this case, if the interrupt of Socket n is activated, interrupt occurs. Refer to Interrupt Register(IR), Interrupt Mask Register (IMR) and Socket n Interrupt Register (Sn_IR). */ }
If user doesn’t need the communication any more, close the Socket n.
{ /* clear remained interrupts */ Sn_IR = 0x00FF; IR(n) = ‘1’; /* set CLOSE command */ Sn_CR = CLOSE; }
The broadcast communication communicates with many and unspecified others. But the multicast communication communicates with many specified others who registered at a multicast-group. Suppose that A, B, and C are registered at a specified multicast-group. If user transmits data to multicast-group (contains A), B and C also receive the DATA for A. To use multicast communication, the destination list registers to multicast-group by using IGMP protocol. The multicast-group consists of ‘Group hardware address,’ ‘Group IP address,’ and ‘Group port number.’ User cannot change the ‘Group hardware address’ and ‘Group IP address.’ But the ‘Group port number’ can be changed.
The ‘Group hardware address’ is selected at the assigned range (From “01:00:5e:00:00:00”to “01:00:5e:7f:ff:ff”) and the ‘Group IP address’ is selected in D-class IP address (From “224.0.0.0” to “239.255.255.255”, please refer to the website;
http://www.iana.org/assignments/multicast-addresses).
When selecting, the upper 23bit of 6bytes ‘Group hardware address’ and the 4bytes ‘Group IP address’ must be the same. For example, if the user selects the ‘Group IP address’ to “244.1.1.11,” the ‘Group hardware address’ is selected to “01:00:5e:01:01:0b.” Please refer to the “RFC1112” (http://www.ietf.org/rfc.html).
In the W5500, IGMP processing to register the multicast-group is internally (automatically) processed. When the user opens the Socket n with multicast mode, the “Join” message is internally transmitted. If the user closes it, the “Leave” message is internally transmitted. After the SOCKET opens, the “Report” message is periodically and internally transmitted when the user communicates.
The W5500 support IGMP version 1 and version 2 only. If user wants use an updated version, the host processes IGMP directly by using the IPRAW mode SOCKET.
Choose one SOCKET for multicast communication among 8 SOCKETS of W5500. Set the Sn_DHAR0 to ‘Multicast-group hardware address’ and set the Sn_DIPR0 to ‘Multicastgroup IP address.’ Then set the Sn_PORT0 and Sn_DPORT0 to ‘Multicast-group port number.’ Set the Sn_MR(P3:P0) to UDP and set the Sn_MR(MULTI) to ‘1.’ Finally, execute OPEN command. If the state of Sn_SR is changed to SOCK_UDP after the OPEN command, the SOCKET initialization is completed.
{ START: /* set Multicast-Group information */ Sn_DHAR0 = 0x01; /* set Multicast-Group H/W address(01:00:5e:01:01:0b) */ Sn_DHAR1 = 0x00; Sn_DHAR2 = 0x5E; Sn_DHAR3 = 0x01; Sn_DHAR4 = 0x01; Sn_DHAR5 = 0x0B; Sn_DIPR0 = 211; /* set Multicast-Group IP address(211.1.1.11) */ Sn_DIPR1 = 1; Sn_DIPR2 = 1; Sn_DIRP3 = 11; Sn_DPORT0 = 0x0BB8; /* set Multicast-GroupPort number(3000) */ Sn_PORT0 = 0x0BB8; /* set SourcePort number(3000) */ Sn_MR = 0x02 | 0x80; /* set UDP mode & Multicast on Socket n Mode Register */ Sn_CR = OPEN; /* set OPEN command */ /* wait until Sn_SR is changed to SOCK_UDP */ if (Sn_SR != SOCK_UDP) Sn_CR = CLOSE; goto START; }
Refer to the “Unicast & Broadcast.” section.
Refer to the “Unicast & Broadcast.” section. Unicast & Broadcast
Since the user sets the information about multicast-group at SOCKET initialization, user does not need to set IP address and port number for destination any more. Therefore, copy the transmission data to internal TX memory and executes SEND command.
{ /* first, get the free TX memory size */ FREESIZE: freesize = Sn_TX_FSR; if (freesize<len) goto FREESIZE; // len is send size /* calculate offset address */ dst_mask = Sn_TX_WR0 &gSn_TX_MASK; // dst_mask is offset address /* calculate start address(physical address) */ dst_ptr = gSn_TX_BASE + dst_mask; // dst_ptr is physical start address /* if overflow SOCKETTX memory */ if ( (dst_mask + len) > (gSn_TX_MASK + 1) ) { /* copy upper_size bytes of source_addr to destination_address */ upper_size = (gSn_TX_MASK + 1) – dst_mask; memcpy((0x0000 + source_addr), (0x0000 + dst_ptr), upper_size); /* update source_addr*/ source_addr += upper_size; /* copy left_size bytes of source_addr to gSn_TX_BASE */ left_size = len – upper_size; memcpy( source_addr, gSn_TX_BASE, left_size); } else { /* copy len bytes of source_addr to dst_ptr */ memcpy( source_addr, dst_ptr, len); } /* increase Sn_TX_WR as length of len */ Sn_TX_WR0 += send_size; /* set SEND command */ Sn_CR = SEND; }
Since the host manages all protocol process for data communication, timeout cannot occur.
{ /* check SEND command completion */ while(S0_IR(SENDOK)==‘0’); /* wait interrupt of SEND completion */ S0_IR(SENDOK) = ‘1’; /* clear previous interrupt of SEND completion */ }
Refer to the “Unicast & Broadcast.” section. Unicast & Broadcast