I still wonder what happens, if you read less bytes from the RX_FIFO than stated in the last PACKET_INFO and then send a RECEIVE command. Later you can still read the remaining bytes of the current packet (and send RECEIVE again), as you still know how much bytes are left. It would be strange, if this shouldn't work, as for the W5300 these are only bytes in its memory and nothing else. In this case you don't need these 8x1500 byte buffers on EP side. But who knows...
Hmm, ok, but then you can say, you don't even read anything and send a RECV command. Or read all the packet then issuing the command. Or only a part of the packet and then. I don't see the difference, and then the question remains: what is the purpose of RECV command, if it is even not interesting when you send it to the w5300? That's why I think it has some important role, just we don't know what. Because if it wouldn't have importance at all, why would it be designed to be used? I am confused with this question a lot.
I just read that, and this seems to be a solution for such a problem that I sometimes have with the W5100 - the connection is sometimes stalled when receiving a lot of incoming data! But I think it's not possible to send an empty package? In the example the dummy data still has a size of 1 byte. Couldn't this cause issues with some protocols?
Well, a TCP packet can carry some informations (like ACK) even with no data payload at all. Then an OS should behave to deal with the information you got from the header, but since there is no application-level data, the application itself is not important here, just the TCP/IP stack of the OS. In our case the "OS" itself at the EP side is the w5300, since it does the TCP/IP "by hardware". I guess even w5300 processes incoming packets with data size zero, and it is not stored then in the RX buffer at all, since it's only connection-organization like information and not user data. Just consider the ACKs. TCP (unlike UDP) is "reliable", ie the receiver (now w5300 for example) should ACK the it for the sender. The ACK itself can be sent as a single packet with no data payload at all (as far as I know ...). It's another question that if the receiver has something to transmit, it's a better strategy to transmit, and use the ACK field of the TCP header to ack the previous receiving in one packet. But it can a case when receiver has nothing to send, but still the sender must be ACK'ed, thus then, a packet should be sent anyway to transmit the ACK without any application payload though. Well, it seems it was long time ago when I tried to write TCP/IP stack for C64 and I digged into TCP more deeply because of the project. Now I am not so sure anymore about the details