Socket Size Registers being read multiple times?

Question

I would like to know why the Sn_TX_FSR and Sn_RX_RSR registers are read multiple times. Is it because their values change after a command is executed? If so, is that the only reason? github.com Wiznet/ioLibrary_Driver/blob/master/Ethernet/W5100/w5100.c#L224-L259 /////////////////////////////////// // Socket N regsiter IO function // /////////////////////////////////// uint16_t getSn_TX_FSR(uint8_t sn) { uint16_t val=0,val1=0; do { val1 = WIZCHIP_READ(Sn_TX_FSR(sn)); val1 = (val1 << 8) + WIZCHIP_READ(WIZCHIP_OFFSET_INC(Sn_TX_FSR(sn),1)); if (val1 != 0) { val = WIZCHIP_READ(Sn_TX_FSR(sn)); val = (val << 8) + WIZCHIP_READ(WIZCHIP_OFFSET_INC(Sn_TX_FSR(sn),1)); } }while (val != val1); return val; } This file has been truncated. show original

bangbh · Answer

Hi. dev07: Is it because their values change after a command is executed? If so, is that the only reason? Yes, It’s because data can come into the chip while a command is executed. And yes, It’s the only reason. Thanks.

dev07 · Answer

bangbh: data can come into the chip while a command is executed. Interesting. I wonder if that applies to the 2 bytes on the headers of UDP/IPRaw/MacRaw payloads. Can the 2 bytes header be wrong because more data arrived between the time I read the it and the time I finish reading the payload? For example, the 2 bytes header indicates there’s 100 bytes to be read. So I proceed to read 100 bytes, but before I finish reading 100 bytes, another 80 bytes arrived, but I will only read 100. What then? Or the 2 bytes header value is only written once, meaning every time data arrives, it will be in a different payload? Also, does reading Sn_RX_RSR at least twice guarantees that more data didn’t arrive between the the time I read it the second time and the time I started reading the RX memory? Or is it just supposed to be a small workaround? And somewhat unrelated to the main topic, but not completely, and because I’m curious about how the inner-workings of the chip: The datasheet states that the Sn_RX_RD and Sn_TX_WR registers change value after RECV and SEND commands. Why? Only their counterparts, Sn_RX_WR and Sn_TX_RD, should change values, indicating that data arrived or that data was sent. I assume we’re talking about a standard ring buffer implementation. Maybe we aren’t. And how does the Sn_IR detects that there is still data to be read in order to keep the RECV bit as 1, even after attempting to clean the register? Does it derives this information from the RX buffer pointers, like Sn_RX_RD and Sn_RX_WR are not equal, or Sn_RX_RSR is not zero, or what?

dev07 · Answer

becky: It is different for each mode I think I said it in a way that was open to be interpreted as all 3 modes having the same 2 bytes header like MAC_RAW. I apologize for not being clear enough. What I meant was I only care about the 2 bytes, because I’m interested in the MAC_RAW mode only. becky: After reading 100 bytes, you can read RX_RSR to check 80 bytes and recv 80 bytes. But what if I don’t read RX_RSR, but read the RX memory and go for the MAC_RAW header instead? Would there be another header + payload there? In other words, can I ignore RX_RSR completely if I use MAC_RAW mode? For instance, In my code below, recvfrom doesn’t take any size parameters, and I only read the S0_RX_RD register: https://github.com/KaeLL/W5100/blob/master/w5100_socket.c#L47-L49 becky: Sn_RX_RD-Sn_RX_WR. The value of Sn_RX_RD is increased when the received data is accumulated in the buffer, and the Sn_RX_WR value is increased by sending the Recv Command after taking the data from the receive buffer and increasing the Sn_RX_WR value. I think you mixed them up. What you’re calling Sn_RX_RD is actually the Sn_RX_WR, and vice-versa. But I’ll continue using your notation. becky: and the Sn_RX_WR value is increased by sending the Recv Command after taking the data from the receive buffer and increasing the Sn_RX_WR value. So the value changes because I changed it, and not because of the successful execution of the SEND/RECV commands, right? That’s my point. And yet, the datasheet states (at the bottom of the image): rx_rd1364×437 32.2 KB which make no sense.

dev07 · Answer

@becky @bangbh any follow up?

dev07 · Answer

Come on, guys. I could really use the help, and I don’t like bumping threads.