WIZ850io is an compact-sized network module that includes W5500(TCP/IP & Ethernet MAC & PHY) & MAG-JACK (RJ45 with X’FMR) with other glue logics. As it is hardware compatible with WIZ820io, you can easily replace the WIZ820io with WIZ850io just by updating the firmwware.

• Plugin Network Module.
• Hardware compatible with WIZ820io.
• Usable without H/W design for W5500, Transformer & RJ45.
• Fast evaluation for W5500 & MCU in the target board.
• Support high speed SPI interface.
• Support power down mode and Wake-on-LAN function
• Very small form factor : 23mm x 25mm x 18mm
• 1 x 6, 2.54mm Pin Header x 2

Download Full DataSheet and Manual: https://www.wiznet.io/product-item/wiz850io/

User need to wait for 50ms after this pin is changed to HIGH to communicate with WIZ850io. (Refer to 5. Timing Diagram)

As WIZ850io consists of W5500 and others, SPI operation of WIZ850io follows one of W5500. For more information about SPI operation of WIZ850io, please refer to W5500 Datasheet.

Go to link bellow for download orginal wiznet w5500 chipset drivers.
https://www.wiznet.io/product-item/w5500/

the WIZnet IOLibrary is a set of libraries provided by WIZnet for their WIZnet devices, particularly for their Internet of Things (IoT) modules and chips. These devices often include embedded Ethernet controllers and are used to enable network connectivity in various embedded systems.

The iolibrary.h header file is likely part of the IOLibrary and may contain declarations and definitions necessary for interfacing with WIZnet devices. It typically provides functions and structures that facilitate communication over Ethernet, TCP/IP, and other networking protocols.

To get detailed and up-to-date information about iolibrary.h or any other WIZnet libraries, it's recommended to refer to the official documentation provided by WIZnet. The documentation usually includes information about the functions, data structures, and usage examples for the library, helping developers integrate WIZnet devices into their projects.

Please check WIZnet's official website or contact their support for the latest documentation and resources related to the IOLibrary and the iolibrary.h header file. Keep in mind that developments and updates may have occurred since my last update in January 2022.

The WIZnet IOLibrary is designed to provide a set of libraries and drivers that can be used with various microcontrollers to enable communication with WIZnet devices, such as their IoT modules and chips. The library is typically written in C to ensure portability and ease of integration into different embedded systems.

The IOLibrary is not tied to a specific microcontroller but is intended to be adaptable to a range of microcontroller architectures. It provides a common set of functions and abstractions for communication over Ethernet and TCP/IP, allowing developers to interface with WIZnet devices using a consistent API.

When using the IOLibrary, you may need to adapt some platform-specific details, such as configuring pins, setting up interrupts, or handling hardware-specific nuances, depending on the microcontroller you are using. However, the core communication and protocol-handling code provided by the IOLibrary remains consistent.

To use the IOLibrary with a specific microcontroller, you would typically include the appropriate header files, link against the library, and implement any necessary platform-specific code or configurations. Always refer to the documentation provided by WIZnet for details on how to use the IOLibrary with your particular microcontroller and development environment.

Download ioLibrary_Driver at this bellow link:
https://github.com/Wiznet/ioLibrary_Driver

Go to the Ethernet directory and copy these file/directory to your src directory of STM32 Project.

• socket.c file
• socket.h file
• wizchip_conf.c file
• wizchip_conf.h file
• W5500 directory

save these file/directory in a folder named ioLibrary_w5500.

Add Library Files:

Create a new folder in your project directory to store the library files if one doesn't exist. Copy the library files (header files and source files) into this folder. Ensure that you have the correct versions of the library compatible with your STM32CubeMX project.

Include Library Files in uVision:

In uVision, right-click on your project in the "Project" tab and select "Options for Target..."
Under the "C/C++" tab, click on "Include Paths."
Add the path to the folder containing your library files.

Add Library Source Files to Project:

Back in the uVision project window, right-click on the "Source Group" where you want to add the library files.
Choose "Add Existing Files to Group..." and select the library source files.

The ioLibrary_Driver typically consists of several folders and files. Some key components include:

• Ethernet Library Files: These files contain the low-level drivers for the Wiznet W5500 chip. Look for files related to socket communication, such as socket.c and socket.h.

• Configuration Files: Check for configuration files that allow you to set parameters for your specific hardware and network setup. Commonly, there's a file like wizchip_conf.h where you define things like the SPI interface, network configuration, etc.

1- Network Information for WIZCHIP

/**
 * @ingroup DATA_TYPE
 *  Network Information for WIZCHIP
 */
typedef struct wiz_NetInfo_t
{
   uint8_t mac[6];  ///< Source Mac Address
   uint8_t ip[4];   ///< Source IP Address
   uint8_t sn[4];   ///< Subnet Mask 
   uint8_t gw[4];   ///< Gateway IP Address
   uint8_t dns[4];  ///< DNS server IP Address
   dhcp_mode dhcp;  ///< 1 - Static, 2 - DHCP
} wiz_NetInfo;

Here's the breakdown of the structure members:

mac[6]: This is an array of 6 bytes representing the MAC (Media Access Control) address. MAC addresses are unique identifiers assigned to network interfaces.

ip[4]: This is an array of 4 bytes representing the IP (Internet Protocol) address. It's the address assigned to the device on the network.

sn[4]: This is an array of 4 bytes representing the Subnet Mask. The subnet mask is used to divide an IP address into network and host portions.

gw[4]: This is an array of 4 bytes representing the Gateway IP Address. The gateway is a node on the network that serves as an access point to another network or the internet.

dns[4]: This is an array of 4 bytes representing the DNS (Domain Name System) server IP address. DNS is used to translate human-readable domain names to IP addresses.

dhcp: This is of type dhcp_mode, which seems to be an enumeration indicating the DHCP (Dynamic Host Configuration Protocol) mode. The comment suggests that a value of 1 indicates static IP, and 2 indicates DHCP.

The typedef keyword is used to create an alias for the structure, allowing you to refer to this structure as wiz_NetInfo instead of struct wiz_NetInfo_t. This can make your code cleaner and more readable.

It seems like this structure is meant to hold network configuration information for a WIZCHIP device, and the comments provide additional context for each member of the structure.

2- dhcp_mode

/**
 * @ingroup DATA_TYPE
 *  It is used in setting dhcp_mode of @ref wiz_NetInfo.
 */
typedef enum
{
   NETINFO_STATIC = 1,    ///< Static IP configuration by manual setup.
   NETINFO_DHCP           ///< Dynamic IP configuration from a DHCP server.
} dhcp_mode;

Here's an explanation of the enumeration:

NETINFO_STATIC = 1: This value indicates static IP configuration. When the dhcp_mode field in the **wiz_NetInfo structure is set to NETINFO_STATIC (or explicitly to 1), it means that the device will be configured with a fixed (static) IP address.

NETINFO_DHCP: This value indicates dynamic IP configuration using DHCP. When the dhcp_mode field in the **wiz_NetInfo structure is set to NETINFO_DHCP, it means that the device will obtain its IP configuration dynamically from a DHCP server on the network.

The typedef enum statement creates a new type (dhcp_mode) that can take on one of the specified values. This enumeration is then used in the wiz_NetInfo structure to represent the DHCP mode for configuring network information.

This setup allows you to easily switch between static and dynamic IP configurations by using the dhcp_mode enumeration in your code. For example:

wiz_NetInfo netInfo;
netInfo.dhcp = NETINFO_STATIC; // Set to static IP configuration

// OR

netInfo.dhcp = NETINFO_DHCP; // Set to dynamic IP configuration using DHCP

3- wiz_NetTimeout
This code defines a structure wiz_NetTimeout that is likely used for timeout configuration. Here's a breakdown of the structure:

/**
 * @ingroup DATA_TYPE
 *  Used in CN_SET_TIMEOUT or CN_GET_TIMEOUT of @ref ctlwizchip() for timeout configruation.
 */
typedef struct wiz_NetTimeout_t
{
   uint8_t  retry_cnt;     ///< retry count 
   uint16_t time_100us;    ///< time unit 100us
}wiz_NetTimeout;

Here are the members of the structure:

• retry_cnt: This is a member of type uint8_t (unsigned 8-bit integer) and represents the retry count. It likely indicates the number of attempts to perform a specific operation before considering it a failure.

• time_100us: This is a member of type uint16_t (unsigned 16-bit integer) and represents the time unit in 100 microseconds. It likely specifies the timeout duration for an operation, and the time is measured in 100-microsecond increments.

This structure seems to be designed to configure timeout parameters for certain operations related to WIZCHIP using the ctlwizchip() function. The ctlwizchip() function is typically used to configure various aspects of the WIZCHIP, and in this case, it seems to be related to timeout settings.

For example, you might use this structure as follows:

wiz_NetTimeout timeoutConfig;
timeoutConfig.retry_cnt = 3;        // Set retry count to 3
timeoutConfig.time_100us = 5000;   // Set timeout to 500,000 microseconds (500 ms)

// Use the structure in ctlwizchip() to set the timeout configuration
ctlwizchip(CN_SET_TIMEOUT, &timeoutConfig);

This is just a hypothetical example, and you should refer to the documentation or source code of the library you are working with to understand the specific usage and context of this timeout configuration structure.

4- reg_wizchip_cris_cbfunc

void reg_wizchip_cris_cbfunc(void (*cris_en)(void), void (*cris_ex)(void));

This function, reg_wizchip_cris_cbfunc, is part of a library or driver for a WIZCHIP device and is used to register callback functions for critical sections of I/O operations. Critical sections are portions of code that must be executed without interruption, especially in a multi-threaded or multi-process environment.

Here's an explanation of the parameters and the purpose of this function:

cris_en: This parameter is a function pointer to the callback function that will be called when entering a critical section. This function is responsible for setting up the critical section, ensuring that the subsequent code executes without interruption.

cris_ex: This parameter is a function pointer to the callback function that will be called when exiting a critical section. This function is responsible for releasing the critical section, allowing other parts of the code to proceed.

@todo: This is a comment indicating that there is a "to-do" item. It suggests that there might be macros or functions (WIZCHIP_CRITICAL_ENTER and WIZCHIP_CRITICAL_EXIT) related to critical sections that should be described or registered. It's a reminder to the developer to provide additional documentation or register custom functions if needed.

@note: This comment informs the user that if they do not describe or register their own functions, default functions (wizchip_cris_enter and wizchip_cris_exit) will be called. This is common in libraries to provide a default behavior if the user does not customize the critical section handling.

In practice, you would use this function to register your own critical section handling functions if the default ones are not suitable for your application or if you want to customize the behavior during I/O operations.

5- reg_wizchip_cs_cbfunc

void reg_wizchip_cs_cbfunc(void (*cs_sel)(void), void (*cs_desel)(void));

This function, reg_wizchip_cs_cbfunc, is part of a library or driver for a WIZCHIP device, and it is used to register callback functions for the WIZCHIP select and deselect operations. These operations typically involve enabling or disabling the chip select (CS) line to communicate with the WIZCHIP device over a SPI or similar interface.

Here's an explanation of the parameters and the purpose of this function:

cs_sel: This parameter is a function pointer to the callback function that will be called when selecting (enabling) the WIZCHIP. This function is responsible for activating the chip select line to prepare for communication.

cs_desel: This parameter is a function pointer to the callback function that will be called when deselecting (disabling) the WIZCHIP. This function is responsible for deactivating the chip select line, indicating the end of communication with the WIZCHIP.

@todo: This comment suggests that there might be functions (wizchip_cs_select and wizchip_cs_deselect) related to WIZCHIP select and deselect operations that should be described or registered. It's a reminder to the developer to provide additional documentation or register custom functions if needed.

@note: This comment informs the user that if they do not describe or register their own functions, null functions will be called. This is a common approach to providing default behavior if the user does not customize the chip select handling.

In practice, you would use this function to register your own chip select handling functions if the default ones are not suitable for your application or if you want to customize the behavior during WIZCHIP communication.

6- reg_wizchip_bus_cbfunc

void reg_wizchip_bus_cbfunc(iodata_t (*bus_rb)(uint32_t addr), void (*bus_wb)(uint32_t addr, iodata_t wb));

This function, reg_wizchip_bus_cbfunc, is part of a library or driver for a WIZCHIP device, and it is used to register callback functions for bus interface operations. The bus interface typically involves reading and writing byte data using the system bus.

Here's an explanation of the parameters and the purpose of this function:

bus_rb: This parameter is a function pointer to the callback function that will be called when reading byte data using the system bus. This function is responsible for reading data from the specified address using the system bus.

bus_wb: This parameter is a function pointer to the callback function that will be called when writing byte data using the system bus. This function is responsible for writing data to the specified address using the system bus.

@todo: This comment suggests that there might be functions (wizchip_bus_readbyte and wizchip_bus_writebyte) related to bus interface operations that should be described or registered. It's a reminder to the developer to provide additional documentation or register custom functions if needed.

@note: This comment informs the user that if they do not describe or register their own functions, null functions will be called. This is a common approach to providing default behavior if the user does not customize the bus interface handling.

In practice, you would use this function to register your own bus interface handling functions if the default ones are not suitable for your application or if you want to customize the behavior during WIZCHIP communication. The commented-out line (// M20150601: For integrating with W5300) indicates a modification for compatibility with a specific version or model of the WIZCHIP device.

7- reg_wizchip_spi_cbfunc

void reg_wizchip_spi_cbfunc(uint8_t (*spi_rb)(void), void (*spi_wb)(uint8_t wb));

This function, reg_wizchip_spi_cbfunc, is part of a library or driver for a WIZCHIP device, and it is used to register callback functions for SPI (Serial Peripheral Interface) interface operations. The SPI interface is commonly used for communication between microcontrollers and peripheral devices.

Here's an explanation of the parameters and the purpose of this function:

spi_rb: This parameter is a function pointer to the callback function that will be called when reading a byte using the SPI interface. This function is responsible for initiating a read operation on the SPI bus and returning the received byte.

spi_wb: This parameter is a function pointer to the callback function that will be called when writing a byte using the SPI interface. This function is responsible for initiating a write operation on the SPI bus with the provided byte.

@todo: This comment suggests that there might be functions (wizchip_spi_readbyte and wizchip_spi_writebyte) related to SPI interface operations that should be described or registered. It's a reminder to the developer to provide additional documentation or register custom functions if needed.

@note: This comment informs the user that if they do not describe or register their own functions, null functions will be called. This is a common approach to providing default behavior if the user does not customize the SPI interface handling.

In practice, you would use this function to register your own SPI interface handling functions if the default ones are not suitable for your application or if you want to customize the behavior during WIZCHIP communication.

8- reg_wizchip_spiburst_cbfunc

void reg_wizchip_spiburst_cbfunc(void (*spi_rb)(uint8_t* pBuf, uint16_t len), void (*spi_wb)(uint8_t* pBuf, uint16_t len));

This function, reg_wizchip_spiburst_cbfunc, is part of a library or driver for a WIZCHIP device, and it is used to register callback functions for burst read and burst write operations using the SPI (Serial Peripheral Interface) interface. The SPI interface is commonly used for communication between microcontrollers and peripheral devices.

Here's an explanation of the parameters and the purpose of this function:

spi_rb: This parameter is a function pointer to the callback function that will be called when performing a burst read operation using the SPI interface. This function is responsible for initiating a burst read operation on the SPI bus and receiving a buffer of bytes.

spi_wb: This parameter is a function pointer to the callback function that will be called when performing a burst write operation using the SPI interface. This function is responsible for initiating a burst write operation on the SPI bus with the provided buffer of bytes.

@todo: This comment suggests that there might be functions (wizchip_spi_readbyte and wizchip_spi_writebyte) related to SPI interface operations that should be described or registered. It's a reminder to the developer to provide additional documentation or register custom functions if needed.

@note: This comment informs the user that if they do not describe or register their own functions, null functions will be called. This is a common approach to providing default behavior if the user does not customize the SPI interface handling.

In practice, you would use this function to register your own SPI interface handling functions if the default ones are not suitable for your application or if you want to customize the behavior during burst read and burst write operations with the WIZCHIP device.

9- ctlwizchip

int8_t ctlwizchip(ctlwizchip_type cwtype, void* arg);

This function, ctlwizchip, is likely part of a library or driver for a WIZCHIP device, and it is used to control various aspects of the WIZCHIP. It provides a way to perform different control operations on the WIZCHIP, such as resetting, configuring the PHY (Physical Layer) mode, monitoring the PHY status, controlling interrupts, and more.

Here's an explanation of the parameters and the purpose of this function:

cwtype: This parameter specifies the type of control operation to be performed. The type is defined by the ctlwizchip_type enumeration, which likely includes various control types like resetting, configuring PHY, monitoring PHY status, and controlling interrupts.

arg: This parameter is a pointer to an argument, and its type depends on the cwtype. The argument carries additional information or data required for the specific control operation.

The function returns 0 on success, indicating that the control operation was executed successfully. If the function returns -1, it indicates failure, which could be due to an invalid or unsupported control type.

The function is part of the "extra functions" group, suggesting that it provides additional and advanced features beyond basic WIZCHIP functionality.

In practice, you would use this function to configure and control various aspects of the WIZCHIP based on your application requirements. The specific control types and their corresponding arguments should be documented in the library or driver's documentation. For example:

// Example usage: Reset the WIZCHIP
int8_t result = ctlwizchip(CW_RESET_WIZCHIP, NULL);
if (result == 0) {
    // Reset successful
} else {
    // Reset failed
}

You should refer to the documentation of the library or driver to understand the available control types and their respective arguments.

10- ctlnetwork

int8_t ctlnetwork(ctlnetwork_type cntype, void* arg); 

This function, ctlnetwork, is likely part of a library or driver for a WIZCHIP device, and it is used to control various aspects related to the network environment, mode, timeout, and other network-specific configurations.

Here's an explanation of the parameters and the purpose of this function:

cntype: This parameter specifies the type of control operation to be performed on the network. The type is defined by the ctlnetwork_type enumeration, which likely includes various control types related to the network environment, mode, timeout, etc.

arg: This parameter is a pointer to an argument, and its type depends on the cntype. The argument carries additional information or data required for the specific network control operation. It is marked as "Inout," indicating that it is both an input and output parameter. The function may modify the data pointed to by arg during its execution.

The function returns -1 on failure, indicating that the control operation was not successful, possibly due to an invalid or unsupported control type. If the function returns 0, it indicates success.

The function is part of the "extra functions" group, suggesting that it provides additional and advanced features beyond basic WIZCHIP functionality, specifically related to network control.

In practice, you would use this function to configure and control various network-related parameters based on your application requirements. The specific control types and their corresponding arguments should be documented in the library or driver's documentation. For example:

// Example usage: Set the network mode
ctlnetwork_type mode_type = NET_CTRL_MODE;
uint8_t network_mode = NET_MODE_CLIENT;
int8_t result = ctlnetwork(mode_type, &network_mode);
if (result == 0) {
    // Set mode successful
} else {
    // Set mode failed
}

You should refer to the documentation of the library or driver to understand the available control types and their respective arguments in the context of network control.

11- ctlnetwork_type

typedef enum
{
   CN_SET_NETINFO,  ///< Set Network with @ref wiz_NetInfo
   CN_GET_NETINFO,  ///< Get Network with @ref wiz_NetInfo
   CN_SET_NETMODE,  ///< Set network mode as WOL, PPPoE, Ping Block, and Force ARP mode
   CN_GET_NETMODE,  ///< Get network mode as WOL, PPPoE, Ping Block, and Force ARP mode
   CN_SET_TIMEOUT,  ///< Set network timeout as retry count and time.
   CN_GET_TIMEOUT,  ///< Get network timeout as retry count and time.
}ctlnetwork_type;

This enumeration, ctlnetwork_type, defines different control types that can be used with the ctlnetwork function. It is likely used to specify the operation to be performed on the network, such as setting or getting network information, setting or getting network modes, and configuring network timeouts.

Here's an explanation of each control type:

CN_SET_NETINFO: This control type is used to set the network information with a structure of type wiz_NetInfo.

CN_GET_NETINFO: This control type is used to get the current network information into a structure of type wiz_NetInfo.

CN_SET_NETMODE: This control type is used to set the network mode, which can include options such as Wake-on-LAN (WOL), PPPoE, Ping Block, and Force ARP mode.

CN_GET_NETMODE: This control type is used to get the current network mode, which can include options such as Wake-on-LAN (WOL), PPPoE, Ping Block, and Force ARP mode.

CN_SET_TIMEOUT: This control type is used to set the network timeout, specifying the retry count and time.

CN_GET_TIMEOUT: This control type is used to get the current network timeout, retrieving the retry count and time.

These control types provide a way to perform specific actions or queries related to network configuration and behavior using the ctlnetwork function. When calling ctlnetwork, you would specify one of these control types based on the operation you want to perform and provide the corresponding argument (if required) based on the control type.

A library developed for STM32 ARM microcontrollers that link is at bellow:
https://github.com/GitMasterNikanjam/ARM_utility/tree/master/Library/wiznet_library

example to use this library:

1- Copy wiznet_library folder in your project. then add path include in c/c++ compiler setting.
2- write #include "wiznet.h" in your 'main.c' file.
3- Open wiznet.h file and edit configuration as your need. Also There are user functions declarations.

#ifndef SRC_W5500_W5500_SPI_H_
#define SRC_W5500_W5500_SPI_H_

#include <stdint.h>

// --------------------------------------------------
// User Functions:

// High level functions
uint8_t wizInit(void);					// Wiznet module initialize according to user parameters
uint8_t wizGetVersion(void);				// Get Wiznet module version number.(just for test connection)
void wizNetSend(uint8_t* data, uint8_t size);		// Send network data as server to client
void wizNetRecv(uint8_t* data, uint8_t size);		// Recieve network data as server from client
void wizOpenListen(void);			        // Open and Listen Socket

// Low level functions
void wizSelect(void);					        // SPI Chip Select Actived for wiznet module 
void wizDeSelect(void);					        // SPI Chip Select Disabled for wiznet module 
void wizSpiWrite(uint8_t wb);				        // SPI write one byte to wiznet module 
uint8_t wizSpiRead(void);					// SPI read one byte from wiznet module
uint8_t wizSpiReadWrite(uint8_t data);				// SPI read and write at same time from wiznet module
void wizSpiReadBurst(uint8_t* pBuf, uint16_t len);		// SPI read some bytes from wiznet module
void wizSpiWriteBurst(uint8_t* pBuf, uint16_t len);		// SPI write some bytes to wiznet module
void wizReset(void);																	// Hardware Reset on Reset pin of wiznet module


// ---------------------------------------------------
// User Define Parameters:

// Reset Port & Pin
#define WIZ_RESET_PORT		        GPIOB
#define WIZ_RESET_PIN			GPIO_PIN_5

// SPI Chip Select Port & Pin
#define WIZ_CHIP_SELECT_PORT		GPIOA
#define WIZ_CHIP_SELECT_PIN	        GPIO_PIN_11

// HAL SPI Struct
#define WIZ_SPI_STRUCT			hspi1

// Net Information
#define WIZ_NET_INFO_MAC		{ 0x00, 0x08, 0xdc, 0x01, 0x02, 0x03 }
#define WIZ_NET_INFO_IP			{ 192, 168, 1, 100 }
#define WIZ_NET_INFO_SN		        { 255, 255, 255, 0 }
#define WIZ_NET_INFO_GW			{ 192, 168, 1, 1 }
#define WIZ_NET_INFO_DNS	        { 8, 8, 8, 8 }
#define WIZ_NET_INFO_DHCP		NETINFO_STATIC

// Buffer TX/RX Size (max = 16)
#define WIZ_TX_BUF_SIZE				2				// K bytes (max = 16)
#define WIZ_RX_BUF_SIZE				2				// K bytes (max = 16)

// Socket Number & Port
#define WIZ_SOCK_NUM				0				// must be in range [0 ~ 7]
#define WIZ_SOCK_PORT				5000

// Net Timeout Parameters	
#define WIZ_NET_RETRY_CNT			3				// Set retry count
#define WIZ_NET_TIMEOUT_100US			10000		// Set timeout. time unit 100us

#endif

4- use functions library in your code. for example:

  while (1)
  {
		uint8_t rc[5];					// Recieve buffer for recieve data at network
                char s[20];					// String data buffer for send data at the network
		uint8_t wiz_version = wizGetVersion();
		sprintf(s,"wiznet version is: %d\n", wiz_version);
		wizNetSend((uint8_t*) s, sizeof(s));
		wizNetRecv(rc, sizeof(rc));
		HAL_Delay(1000);
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
  }