--- title: "Esperimenti con W5500(Experiments with W5500)" url: "https://maker.wiznet.io/teddy/projects/esperimenti-con-w5500-experiments-with-w5500/" markdown_url: "https://maker.wiznet.io/teddy/projects/esperimenti-con-w5500-experiments-with-w5500/md" type: "UCC: User Created Content" author: "Emilio PG Ficara" author_url: "http://ficara.altervista.org/?p=3463&doing_wp_cron=1666595045.9563279151916503906250" editor: "WIZnet" editor_url: "https://maker.wiznet.io/" original_author: "Emilio PG Ficara" original_url: "http://ficara.altervista.org/?p=3463&doing_wp_cron=1666595045.9563279151916503906250" published: "2022-10-24" language: "en" tags: ["W5500"] likes: 4 views: 1134 comments: 0 source: "WIZnet Makers (https://maker.wiznet.io/)" --- # Esperimenti con W5500(Experiments with W5500) > After designing some devices with WiFi modules based on the ESP8266 component, I decided to switch to "wired" mode, because they pointed out Original author: Emilio PG Ficara (source: http://ficara.altervista.org/?p=3463&doing_wp_cron=1666595045.9563279151916503906250) ## Article ## Experiments with W5500 Written on[25 FEBRUARY 2017](http://ficara.altervista.org/?p=3463) After designing some devices with WiFi modules based on the ESP8266 component, I decided to switch to "wired" mode, because they pointed out to me that many people turn off the WiFi section of the modem / router when they do not need them to "surf" and therefore any wireless-based home automation devices become unusable! At this point, I decided to make a version of my devices also on wired LAN and I therefore looked for a suitable component. There are several options, but after some considerations on cost and availability I decided to focus on the W5500 chip. The [**manufacturer's site**](http://www.wiznet.io/product-item/w5500/) provides extensive and accurate documentation, both for hardware and software. There are updated software libraries and many examples related to the management of the various protocols, but (as always) I have decided to study the component datasheet and write my own test programs from scratch. To start doing some practical tests, I bought on-line a module that houses the component, with the essential minimum of hardware for connection to the external microcontroller and to the LAN. [![](http://ficara.altervista.org/wp-content/uploads/2017/02/pinout-pic.jpg)](http://ficara.altervista.org/wp-content/uploads/2017/02/pinout-pic.jpg) *On the right the module connected with a flat cable to the micro; on the left the detail of the pinout* Unfortunately, I could not reuse any of the software written for the ESP-01, ESP-07 modules etc., because the W5500 has a completely different architecture and driving mode. Meanwhile, from the hardware point of view, the connection takes place via SPI (therefore a synchronous serial) and not via UART; then, the embedded TCP stack requires programming at a lower level, a bit more complex "socket" management. For this first part of the experiment I recycled an old card of mine, based on the Atmel ATmega88 microcontroller, which I had made in the past to drive the well-known ENC28J60 from Microchip. Since that chip was also driven by SPI, I removed the IC (which was in the DIP version and mounted on a socket) and I connected the various signals of the synchronous serial to the connector of the W5500 module. In this way I was able to reuse also the part of the software that managed the SPI communication. The test circuit looks like this: [![](https://maker.wiznet.io/upload/mirror/body/658e1b747a3137bbe8a4.jpg)](http://ficara.altervista.org/wp-content/uploads/2017/02/prototipo-pic.jpg) *The first prototype: board with micro ATmega88, W5500 module and USB-TTL interface for program debugging.* The wiring diagram of the microcontroller board, modified and simplified from the original version with the ENC28J60 chip, is this: [![](http://ficara.altervista.org/wp-content/uploads/2017/02/EF198RasLan-sch-960x635.jpg)](http://ficara.altervista.org/wp-content/uploads/2017/02/EF198RasLan-sch.jpg)For a more detailed view, you can download the file in PDF format from this [**link**](http://ficara.altervista.org/wp-content/uploads/2017/02/EF198RasLan-sch.pdf) . As can be seen from the note on the diagram, at the present time the I / O lines of the micro that have not been used are "floating", waiting to define an additional hardware, but when the project is finished, **each** unused line **must** be suitably connected to a reference. Typically, since the micro at reset places all the I / O in Input conditions (high impedance), it is possible to connect all the unused pins together and use a single resistor to connect them all to GND. Obviously, in the initialization phase of the I / O lines of the firmware, this circuit solution must be taken into account. ## Brief description of the component The IC provides the designer with a complete TCP stack, with 8 independent sockets and a dedicated RAM memory area. Operation is checked by writing or reading some registers and memory areas via the SPI synchronous serial interface. There are three memory blocks: **Common Register Block** , where we find the control registers **Socket Register Block** , where we find the registers relating to the 8 Sockets **Memory,** where we find the read / write buffers of the 8 Sockets The SPI serial can be used to read / write a fixed (1,2,4 bytes - **FDM** ) or variable (n Bytes - **VDM** ) quantity of data. To use the latter mode, it is necessary to drive the **/ CS** (Chip Select) line to inform the chip of the start and end of a data stream. In my project I used this mode exclusively. A write / read stream consists of three phases: **Address Phase** , **Control Phase** , **Data Phase** . In the **Address Phase** 2 bytes are sent which constitute the offset address with respect to the source of the selected memory block; in the **Control Phase** a single byte is sent indicating the memory block to be selected, the **RD** / **WR** mode and the **FDM** / **VDM** mode ; finally, in the **Data Phase** the data are written or read (therefore, in the case of VDM mode this phase has a variable number of bytes). In order to carry out any operation it is necessary to initialize some main registers. When reset, the chip assigns default values; many of these will not need to be modified, as they are the most suitable for normal operation. For example, the registers that determine the amount of RAM allocated to the 8 sockets are initialized with the value of 2K Bytes. By doing so, we will have the memory space evenly distributed among the 8 sockets, for a total of 16K Bytes in writing and as many in reading. Of course, the memory space can be distributed in a different way, as long as the maximum amount of RAM available is respected, which is, in fact, 16K Bytes for the TX buffers and 16K Bytes for the RX buffers. ## Shall we turn it on? Yes, let's turn it on! Well, the circuit is there, let's start with the first step: connect our device to the LAN and try to see if it responds to the "ping". As usual, I did not use "pre-cooked libraries", but I wrote the program starting from the study of what I need, reflecting well on the minimum necessary to achieve the goal. I don't like the approach that (unfortunately) has taken hold in recent years, that is, that of making huge software structures and then defining them as “scalable”. This "scalable" often means that if I only need a fraction of it, I have to take a big block and then take out what is in excess. In my long experience I have been able to ascertain that it is much earlier to write the essential from scratch than to remove 90% of the useless; it is like building a coffee cup starting from a block of marble two meters long on each side, with great effort of chisel and hammer. I prefer to use a "3D printer" and create what I need using only the necessary material. Our device connects to a LAN, typically provided by the modem / router that connects us to the provider. Keep in mind that the w5500 chip does not have ready-made protocols, but it provides us with some TCP / UDP sockets and then ... we have to write the protocol! Therefore, there is no DHCP ready to use and therefore we will program a **static IP** in the internal registers of the chip , which will be what we will then try to "ping". Another very important data to write in the registers is **the physical address**of our device, commonly called MAC address. The MAC address consists of 6 bytes; the first three identify the manufacturer of the hardware and the second three are at the discretion of the manufacturer, who encodes them in the way he likes, while maintaining the uniqueness of the triplet. Particularly important is the first byte of the first triplet and in particular, of this, the second least significant bit. This bit, in fact, determines if the MAC address is **OUI** (Organizationally Unique Identifier) ​​or if it is “locally administered”. Basically, if the first byte of the MAC is xxxxxx **1x** , the device **won't**it belongs to one of the industries registered as producers, but is locally administered. The last (least significant) bit of the first byte determines whether the connection is multicast or unicast. We will only use unicast and therefore this bit will always be zero. A trick to create a physical **OUI** address , which I have seen used in first generation "very cheap" Chinese tablets (in 2011), is to use the one of the router to which you connect as the MAC of the tablet, modifying the last byte by +1 or -1. Ingenious, but you shouldn't do it! If you want to know what your router's MAC is and use the same trick, you can use the ARP command from the Windows DOS window. [![](https://maker.wiznet.io/upload/mirror/body/65727d12d5f774321693.jpg)](http://ficara.altervista.org/wp-content/uploads/2017/02/arp-ss.jpg)This command asks the system to return the MAC address (through the ARP protocol) of the device that has IP 192.168.1.1 (typically the home router). The other two essential data to program in the W5500 registers will be the IP of the Gateway (our modem / router) and the Network Mask. All these data reside in the flash memory of the ATmega88 micro, statically allocated with this assignment: [![](https://maker.wiznet.io/upload/mirror/body/39a84c3a8d2aec81b815.jpg)](http://ficara.altervista.org/wp-content/uploads/2017/02/flash-locate-src.jpg)As you can see in the figure, at location 0x0EC0 we find 64 bytes of flash memory reserved for data for personalizing the device. Note that there is only one byte defined in the source in ' **C** '! This only serves to make the compiler generate a line in the ***raslan.hex*** output file with the reference to the address 0x0EC0. Then, an application on a PC will add the customized data to the .hex file. Here's what the home screen of that application looks like: [![](https://maker.wiznet.io/upload/mirror/body/0fb3c65207376e22f8c9.jpg)](http://ficara.altervista.org/wp-content/uploads/2017/02/raslan-prog-ss.jpg)In the window at the top right we will be able to write, one data per line, the correct values ​​to customize our device according to the network to which we will have to connect it. When the [ *Modify HEX file* ] button is clicked, the program generates a new file called ***raslan-mf.hex*** which contains, in the dedicated flash area, the customized parameters. At this point we can use this file to program the microcontroller. In this first version of the program, the micro sends the parameters read from its flash memory on the serial port (9600, N, 8,1). After transmitting each message, the micro writes the same data in the relative registers of the w5500 and therefore waits for serial commands or ICMP Ping requests. [![](https://maker.wiznet.io/upload/mirror/body/b9e2ba7f202285921dde.jpg)](http://ficara.altervista.org/wp-content/uploads/2017/02/init-w5500-src.jpg)As you can see in the listing, the first operation that is performed on the registers is the reading of the chip version. The w5500 responds with the value 04. This read is also useful for verifying that the SPI read / write routines are effective. Below, we find the writing of the various parameters we have talked about. Let's now connect a USB-Serial converter to the circuit and launch a serial terminal program. In the zip file made available for download you will also find my small terminal program, which you can use to view the output of the micro and to send commands. In this very first release of the software, the only command accepted by the serial is the '+' character which causes a reset from the micro watchdog, thus making the initialization procedure repeat. Here's what we read about the terminal window: [![](http://ficara.altervista.org/wp-content/uploads/2017/02/terminal-boot-ss.jpg)](http://ficara.altervista.org/wp-content/uploads/2017/02/terminal-boot-ss.jpg)At this point we will see the red LED of the circuit send a small flash every 3 seconds, a sign that everything runs smoothly. From the previous image we see that the ***Device IP*** is set to 192.168.0.123 and then we try to ping from a computer connected on the same subnet. The result will be this: [![](http://ficara.altervista.org/wp-content/uploads/2017/02/first-ping-ss.jpg)](http://ficara.altervista.org/wp-content/uploads/2017/02/first-ping-ss.jpg)WELL ! The circuit responds to the Ping! The first step is done! The registers have been initialized successfully. ***We can now, as a test, run the w5500prog.exe*** program again to modify the parameters and reprogram the micro with another ***IP Device*** . Then, we can try to "ping" the new IP and see if it responds to us (it will). Important note: when programming the micro flash memory, the “fuses” must also be set according to this configuration: **H** fuse: **0xCD L** fuse: **0xFC E** fuse: **0xF9** . In the file w5500-v1.zip made available for download you will find these elements: ***miterm.exe*** - the serial terminal ***raslan.hex*** - the basic hex file, without parameters ***raslan-mf.hex*** - the hex file with the parameters, from use to program the micro ***w5500prog.exe*** - the application to modify the parameters ## Proof of the Socket After this very first test, let's start the second and last part of the experiment: the test of a TCP “socket”. To give the program some flexibility, I added a series of commands that can be sent from the serial port. The first of these allows you to enter an IP to which you want to connect. From serial we will write " **i** " and a " **? **“, Then we will write the IP that interests us. Since we have not yet programmed a **DNS client on the micro, we will use a Windows *cmd*** terminal and the **nslookup** command to obtain the IP of the server to connect to. Here is an example: [![](http://ficara.altervista.org/wp-content/uploads/2017/02/nslookup-ss.jpg)](http://ficara.altervista.org/wp-content/uploads/2017/02/nslookup-ss.jpg)With this ***nslookup*** we ask the DNS server 8.8.8.8 (that of Google) the current IP of the robotop.eu5.org site, which is my test site hosted on a free web space. Another serial command allows you to set the port to which you want to connect. On the serial terminal we will write " **p** " and the character " **? **”And then we will enter the Port number, in this case 80 because we want to connect to a web server which will return an HTML page. Now let's see the command that allows us to select the path of the page we want to access, on the site for which we have obtained the IP. On the serial terminal we will write " **s** " and receive the usual " **? **”And at this point we will write the path, for example: ***/php/ipget.php*** . The maximum accepted string length, as in all other commands, is 31 characters. We now have the command to enter the site URL. We will write from the serial terminal " **u** " ​​and we will be shown the usual " **? **"; at this point, we will insert the string, for example ***robotop.eu5.org*** . Someone will wonder why we enter the URL of the site, since we have already obtained the IP with **nslookup** . The reason is that the same host contains many sites (it is a free hosting) and therefore in the HTTP GET request we will make, we will have to add the "Host:" field which will specify which site we want to access, on the server running at that IP address . The last command we can give from the serial is: " **g** ". This command starts an HTTP GET request with the parameters set by serial and those programmed in the flash. The data received (if the request is successful) are limited to 255 bytes. Any excess data is truncated. Let's see an example on the serial terminal: [![](http://ficara.altervista.org/wp-content/uploads/2017/02/socket-get-ss.jpg)](http://ficara.altervista.org/wp-content/uploads/2017/02/socket-get-ss.jpg)I used the command ctrl-r of the serial terminal to record the whole procedure, starting from the reset of the circuit carried out by sending the " **+** " character. Here it is below: ``` > Boot > Chip version: 04 > Device MAC: 02-00-00-00-00-01 > Device IP: 192.168.0.100 > Gateway IP: 192.168.0.1 > Network Mask: 255.255.255.0 > i ? 5.9.82.16 err: editing not allowed ! > i ? 5.9.82.18 > Destination IP: 5.9.82.18 > p ? 80 > Destination PORT: 80 > s ? /php/ipget.php > Server's path: /php/ipget.php > u ? robotop.eu5.org > Server's URL: robotop.eu5.org > g # socket open; src port:1326 # socket initialized OK # connect socket to server... # [3] status=15 # socket connected # sending data... # data received on socket - bytes:00AD HTTP/1.1 200 OK Date: Tue, 07 Mar 2017 16:33:20 GMT Server: Apache X-Powered-By: PHP/5.4.17 Content-Length: 11 Connection: close Content-Type: text/html 5.170.76.79 # closing socket... # closed > ``` Here's what we did: We logged into ***http://robotop.eu5.org/php/ipget.php*** and got a response. The answer is ... our public IP, the one with which our router is seen by the network. The contents of the ipget.php file are very minimal .. here it is: <? Php echo $ _SERVER [REMOTE_ADDR]; ?>. **The experiment is over. **In the new w5500-v2.zip file you will find the updated programs. In the next article I will describe a practical application of what I have experienced so far. It will be a relay that we can turn on / off via the Internet, using any mobile device with internet connection (with the standard browser) as a remote command. We won't have to enable particular ports on the modem / router and we can also use a 3G / 4G router (like the one I'm using right now) that doesn't have a public IP (it's part of a provider's subnet). We will still be able to control our relay (with a few minutes of latency), thanks to a couple of PHP scripts that we will write on any ***free*** hosting , after having done our registration. **Seeing is believing ! **Until we meet again… **Disclaimer:The program or software described, freely downloadable from the site, is to be considered a free "demo" and therefore the author Emilio PG Ficara will not provide any support, nor will he assume any responsibility for any problems or damages o consequence that it should occur in the download or execution of the application.** [**By clicking this link to download the file you implicitly declare that you have read and understood the disclaimer and accept it.**](http://ficara.altervista.org/wp-content/uploads/2017/03/w5500-v2.zip) Check the MD5 checksum of the downloaded w5500-v2.zip file! This must be: **E71F4C2707932F8A2EBCC8C5815D109B** ; if it is different, the file is corrupt or not the original one. In this case, don't unpack it and throw it away! If everything is ok, you can unpack it ( **use the 7Z program and the password "eficara"** ). You can also use the programs on a USB memory stick, as they do not need installation, being pure executables. --- Source: https://maker.wiznet.io/teddy/projects/esperimenti-con-w5500-experiments-with-w5500/