Change Module wiz812mj for wiz810smj ver 1.0, request operation for 100mhz internal clock

[David_Effio_Bustaman]

Hello and good day, I have made the change of module from the model wiz812mj to wiz810smj to improve the transfer speed but without reaching what was expected.

The hardware is an x86, the module works under the bus mode because the processor does not support the spi protocol, the firmware made for wiz812mj works perfectly for the wiz810smj model without any changes by performing the following operations:

1. Reset Module
2. Get IP from DHCP
3. Set mode Server
4. Diagnosis for send and receive data.

When the test of sending data from the module to the host is done, a speed of 90,000 bytes per second is reached, this happens in both the wiz812mj and the wiz810smj without modifying the firmware.

The code to switch the wiz810smj from 25mhz to 100mhz has been added to the firmware and the same speed is obtained: 90,000 bytes per second. why?

The following steps have been done to change the clock from 25mhz to 100mhz:

1. Unlock Register CLKLCKR (Writting 0xCE to 0x0070 address)
2. Config MR2 (Writting 0x40 to 0x0030 address)
3. Unlock Register PHYLCKR (Writting 0x53 to 0x0072 address)
4. Config PHYCR1 (Writting 0x01 to 0x0047 address)

… and nothing more.

we still get the same speed of 90,000 bytes per second.
Is there any way to check that it has really changed from external clock to internal 100mhz?

After adding the clock change, the affected registers have been read obtaining the following values:
MR2=0x40
PHYCR1=0x00

Thanks for you Help.

[becky]

Sorry, but the network performance of WIZ812MJ and WIZ810SMJ is the same. WIZ810SMJ is a product with functions such as ping block and socket less command added to WIZ812MJ.
If you want to speed up, try changing the Socket Size.
In the w5100s, the socket buffer size is allocated to 4 Rx buffers and 4 TX buffers, each 2KB. If you use only one socket, try allocating 8kb to socket 0.
If it still does not improve, it is recommended to use the 16bit bus of WIZ830MJ.

[David_Effio_Bustaman]

Thanks for the recommendation, we finally found a solution to the speed issue and it has been to recode the cpu instructions to speed up the data transfer and we were able to reach up to 2Mbytes/sec or 16Mbits/sec in both WIZ812MJ and WIZ810SMJ modules, we had to do some auxiliary programs in order to measure the speed (Windows Software), and we found an error that happens with WIZ812MJ when it works with indirect and auto increased bus mode. Both modules are programmed in this mode and as a TCP server, for data transmission tests and speed measurement the client (Windows Software) connects to the server and sends it 1 byte, the server responds with 8,192 bytes, the client receives these 8,192 bytes, checks the values ​​sent and sends 1 byte back to the server, repeating the cycle indefinitely. During the first seconds WIZ812MJ responds correctly and later it fails as shown in the first graphic, this is because initially the Sn_RX_RSR register responds correctly indicating that it has received a byte from the client, but for some reason after a few seconds it indicates that it has received several bytes generating a number of transfers of 8192 bytes out of control and out of sync with the client, which is shown in the peaks of the network data measurement indicated by the red arrows of the first graph.
It is impossible for the client to send more than 1 byte since the instruction is encoded directly in the text of the program where it is indicated to send “1”, no variables are used.
The error does not happen with WIZ810SMJ, it works correctly all the time and in order not to have problems with the WIZ812MJ we had to configure it to work in indirect bus mode without auto increment. Finally WIZ812MJ worked correctly with this last mode for more than 1,264 seconds as shown in the second graph. We share this experience so users can take their precautions, the WIZ812MJ version we use is 1.1. The project consists of adapting a brand capture scanner that originally works with RS-232 to work with USB native (No adapters) and WIFI systems in such a way that it accelerates its capture performance and the objective has been reached with these prototypes.

First Graph.

Second Graph

Prototypes.