W5500 buffer address clarification

Question

I’m writing a W5500 driver from scratch. The documentation for the W5500 does not explain the buffering concept well. It appears to be a circular buffer for which the driver code is responsible for maintaining the write address. I assume the chip maintains the read address. Is this correct? Reading the Sn_TX_WR register, is the value an absolute address, or relative to an internally-calculated base address for the socket? In other words, if I write a 0 to Sn_TX_WR, will that always select the first byte of the buffer, no matter what socket? If I write Sn_TX_WR with an address beyond the range for that socket, is it automatically wrapped back to the start of the buffer? In other words, does the driver code need to AND the address with a mask before writing it to make sure it does not go beyond the top of the buffer? If this is the case, then I presume the mask will change depending on the size specified for the buffer? Then by default the mask would be 0x7ff for a 2k byte buffer? TIA

Eugeny · Answer

Refer to W5100 datasheet, it has concepts explained very well.

Eugeny · Answer

tomd: That makes sense too. Is that right? Yes. tomd: but I am imagining that would have required more transistors and so was left to the firmware. I think it is made this way for compatibility reasons with applications designed for earlier devices allowing random parallel access to its buffers (e.g. W5100).

tomd · Answer

I noticed the 5500 sheet says that Sn_TX_RD increments up to Sn_TX_WR after the transmission is complete. So yes, the chip is not counting the bytes coming in, it just writes them into RAM and then you have to tell it where the end is. So therefore 1. there is no reason ever to read Sn_TX_RD as at the end of a cycle Sn_TX_RD == Sn_TX_WR and 2. one could keep a copy of Sn_TX_WR in local RAM, and avoid the register read at the beginning of the cycle. That is, assuming one clearly understood the pointer math involved and so could duplicate the math in firmware. The 5100 sheet has code that demonstrates how to calculate the physical addresses. But the 5500 sheet does not refer to the 5100 sheet, so we are just assuming that it is the same. The 5500 sheet explains (poorly) a scheme which seems to indicate you don’t need a physical address, it seems to be saying that you just treat the point as a 16 bit unsigned and it automagically keeps it within the range of the particular socket’s buffer. Or maybe not. Maybe its saying all the buffers are in a 64k memory space and adding 1 to 0xffff gives you 0. The reference is figure 20, which has arrows pointing all over the place and Lord knows what it means. Quoting page 32: “The Socket n TX Buffer Block allocated in 16KB TX memory is buffer for saving data to be transmitted by host. The 16bits Offset Address of Socket n TX Buffer Block has 64KB address space ranged from 0x0000 to 0xFFFF, and it is configured with reference to ‘Socket n TX Write Pointer Register (Sn_TX_WR)’ & ‘Socket n TX Read Pointer Register(Sn_RX_RD)’. However, the 16bits Offset Address automatically converts into the physical address to be accessible in 16KB TX memory such as Figure 20. Refer to ‘Chapter 4.2’ for Sn_TX_WR & Sn_TX_RD.”

4jochen · Answer

I did not code the W5100 or W5500 buffer management myself for a very long time. Actually did that only for the W3100 in the early years. But, the W5500 has now an advaced hardware buffer management to reduce load on the MCU calculating addresses and moving memory content around. Also the SPI I/F is much more effective compared W5100 to W5500. So, the documentation of W5100 is not that much helpfull for the W5500 here. Maybe you can just re-engineer a little and have full understanding quite quickly by starting here: http://wizwiki.net/wiki/doku.php?id=products:w5500:application:tcp_function e.g. scroll down to → ESTABLISHMENT: Check send data / Send process

Candela12 · Answer

For reference I’ve put my flowchart on the web below: 1790×1029 37.1 KB Every rectangle is a w5500 register read or write. Which it is depends on the “r” or “w” in the corner. rectangles attached to eachother are combined writes (either by DMA, or by BEN, which is a SPI mode on my micro with a 16-byte deep SPI, so fairly asynchronous for short commands. ) The scheme is for simple UDP based packet sending. Receive and send use distinct sockets, and send is typically broadcast to a port. There can be multiple send sockets. Interrupts are configured that the only interrupt is the receive interrupt of the socket used for the receive process. The 4kb receive buffer rotates through the W5500’s 16-bit addressspace. I typically poll RSR on interrupt, calculate if there is new data, and then process. If head and tail of the buffer are more than 2k apart, I use the procedure marked as “discard” to synchronize the pointers again. Send is self contained and does not rely on discard. I’ve got an 16-bitter, so the 16-bit integers used for the pointer values wrap around in the same way as the W5500, and I only have to take care of watching wraparound if calculate the new number of bytes A round trip (receive a 10-20 byte packet and reply to it) takes about 100us, of which about 15us are really CPU time. ( 60MHz/MIPS dspic33EPxxxMU8xx)

Candela12 · Answer

Note that it is packet based (broadcast) UDP only. No DHCP (but I guess that could be added), no TCP, so no HTTP etc. We use it to communicate between boards (and PC) in machine control. Usually only the PC talks to the outside world, so no need for anything else. The current way has good realtime characteristics (never hold up the CPU for more than 10us, and typically about than 5us at a time), and is easy.

Candela12 · Answer

I uploaded the png again.