ENTERPRISE KLUB
2019. május 25., 1055 Budapest, Nyugati tér 9. 14-19 óráig
Részletek
Welcome, Guest. Please login or register.


Author Topic: Wiznet 5100/5300 /etc and Enterprise (Read 11257 times)

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 38.0 Firefox 38.0
    • View Profile
    • http://lgb.hu/
Re: Wiznet 5100/5300 /etc and Enterprise
« Reply #90 on: 2015.July.06. 14:02:42 »
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... :ds_icon_frown:

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.

Quote
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 :(
« Last Edit: 2015.July.06. 14:30:50 by lgb »

Offline BruceTanner

  • EP user
  • *
  • Posts: 482
  • Country: gb
  • OS:
  • Windows NT 6.3 Windows NT 6.3
  • Browser:
  • Chrome 43.0.2357.130 Chrome 43.0.2357.130
    • View Profile
Re: Wiznet 5100/5300 /etc and Enterprise
« Reply #91 on: 2015.July.06. 14:39:42 »
Hmm, do you mean EXOS 9, or really 10? But the problem - I think - is not exactly this, but the fact that - as far as I can see - with disk files EXOS will return less bytes than asked on reading only in case of EOF (so no more bytes). Thus, maybe many EXOS apps can think that less bytes read than requested is the sign of end-of-file, so game over. With network channels the situation is not that (so not compatible) as EXOS call for a network channel can return less bytes than requested because of no data is sent by the network peer. But in this case this does not mean end-of-file, but the app should re-try later if more data is received meanwhile.

So basically me problem: EXOS apps maybe used to deal with "real files" behind the notion of "channels", but in our case network channel is a bit different as it's not an "already ready" stream of data on the disk, but received on reading, etc, in "real time". The problem that we can ask (maybe with EXOS 9) if there is any byte to read or not, but we don't know how much is that "any". Also, if EXOS 9 returned with "no characters" then what an app can think: "end of file" (closed connection like stuff) or just try to re-ask later. Maybe network channels are more like KEYBOARD: EXOS device than "real" files! And that is what EXOS apps are maybe not ready. For newly written apps it may be not a problem.

A tcp/ip connection is just a stream of bytes with no meaning, it is not a file level protocol, and in that respect yes it is more like an EXOS keyboard channel than a disk channel. LOAD, SAVE etc need a file level protocol as they have filenames, file sizes etc. and I wouild think most EXOS apps will be like this. So I think FTP:, HTTP: etc will need to block for the reasons you say, but that's ok because they know how many bytes are arriving and EXOS is a synchronous system (and if the expected bytes don't arrive within a reasonable time the protocol has broken and an error will be returned). You will LOAD "FTP:..." or LOAD "HTTP:..." but you will not LOAD "NET:192.168...". So maybe NET: channels should be non-blocking but FTP: etc channels will block.

EXOS 10 might be able to work with the higher level (FTP: etc) protocol but I don't know them in enough detail to know for sure. I'm pretty sure it would with SMB though.

In your BASIC POP3 app example I guess you would use INPUT # to read and PRINT # to write to the POP3 server so if the TCP/IP channel behaves like the keyboard channel that won't be bad. Not the most efficient way to transfer a large email message though...

I know your dislike of FTP: and you undoubtedly know more than me about it. From a user's perspective though running an FTP server on a PC and being able to LOAD and SAVE to it might be the easiest way of getting files on and off the EP, which is my initial target. Other possibilities as we have discussed before are HTTP: (not sure of the ease of doing other file operations) and SMB: (designed to match MS-DOS functions and therefore EXDOS functions and the basis of Windows resource sharing, but not sure how much it has evolved to be difficult!).

Offline Prodatron

  • EP fan
  • *
  • Posts: 249
  • Country: de
  • Back on the Z80
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 38.0 Firefox 38.0
    • View Profile
    • http://www.symbos.de
Re: Wiznet 5100/5300 /etc and Enterprise
« Reply #92 on: 2015.July.06. 14:49:31 »
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 think it's only to tell the W5300, that the buffer size changed. The buffer memory is the only place, which stores the information about the received packages (packet_info + data). But it's still only a FIFO buffer/data stream. So why should it be important to fetch the complete package?

Quote
Well, a TCP packet can carry some informations (like ACK) even with no data payload at all.
The example code on page 95 seem to send exactly 1 byte:

Code: [Select]
/* set RECV command */
Sn_CR = RECV;
/* Add the code that notifies the update of window size to the peer */
/* check the received data process to finish or not */
if(Sn_RX_RSR == 0) /* send the window-update packet when the window size is full */
{ /* Sn_RX_RSR can be compared with another value instead of ‘0’,
according to the host performance of receiving data */
    Sn_TX_WRSR = 0x00000001; /* set Dummy Data size to Sn_TX_WRSR */
    Sn_TX_FIFOR = 0x0000; /* Write Dummy Data into TX memory */
    Sn_CR = SEND; /* set SEND command */
    while(Sn_CR != 0x00); /* check SEND command completion */
    while(Sn_IR(SENDOK) == ‘0’); /* wait for SEND OK */
    Sn_IR(SENDOK) = ‘1’; /* Clear SENDOK bit */
}

When using a TCP connection with the W5300 there doesn't seem to be a possibility just to send an ACK package.

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 38.0 Firefox 38.0
    • View Profile
    • http://lgb.hu/
Re: Wiznet 5100/5300 /etc and Enterprise
« Reply #93 on: 2015.July.06. 14:50:37 »
Well, something has just crossed my mind: EXOS 11, aka special functions. There are some "sub calls" there involves "the network". Of course it is _not_ that network we mean it now :) but anyway, the basic problems can be similar (block, should not block, special calls via EXOS 11 etc). I am not sure if it's useful, but maybe some can learn from the already ready EXOS parts dealing _a bit_ similar situations ... Eg, over SERIAL stuff, there are situations too that you have no ready data yet, etc.

http://ep.homeserver.hu/Dokumentacio/Konyvek/EXOS_2.1_technikal_information/exos/serial/

Regard to the original issue: I am quite interested what happens if an FTP: (or HTTP: whatever) like EXOS device would be ready and some use it to LOAD a program. It's quite possible that some of the calls can catch a time when 0 bytes are ready to read, or maybe not zero, but less than the requested size. It would be a great test to try, what happens then, would LOAD stopped as treating that end-of-file or what. I have no idea at all, I am not familiar with EXOS at this level ...

Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 38.0 Firefox 38.0
    • View Profile
    • http://lgb.hu/
Re: Wiznet 5100/5300 /etc and Enterprise
« Reply #94 on: 2015.July.06. 14:58:03 »
I think it's only to tell the W5300, that the buffer size changed. The buffer memory is the only place, which stores the information about the received packages (packet_info + data). But it's still only a FIFO buffer/data stream. So why should it be important to fetch the complete package?
The example code on page 95 seem to send exactly 1 byte:

Code: [Select]
/* set RECV command */
Sn_CR = RECV;
/* Add the code that notifies the update of window size to the peer */
/* check the received data process to finish or not */
if(Sn_RX_RSR == 0) /* send the window-update packet when the window size is full */
{ /* Sn_RX_RSR can be compared with another value instead of ‘0’,
according to the host performance of receiving data */
    Sn_TX_WRSR = 0x00000001; /* set Dummy Data size to Sn_TX_WRSR */
    Sn_TX_FIFOR = 0x0000; /* Write Dummy Data into TX memory */
    Sn_CR = SEND; /* set SEND command */
    while(Sn_CR != 0x00); /* check SEND command completion */
    while(Sn_IR(SENDOK) == ‘0’); /* wait for SEND OK */
    Sn_IR(SENDOK) = ‘1’; /* Clear SENDOK bit */
}

When using a TCP connection with the W5300 there doesn't seem to be a possibility just to send an ACK package.

ACK is a different thing, I just mentioned as an example, but this is only for window size update notification purpose. ACK can be transmitted without data, just it's internal to the w5300, a programmer can't do that (it's done by w5300 internally, it has even settings to delay ACKs or not, etc). This window size update is another thing, just I am surprised what happens now, as the code example transmits a byte! So you have an extra unwanted byte sent, and received by the peer. I am confused with this one, really.


Offline lgb

  • EP addict
  • *
  • Posts: 3496
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 38.0 Firefox 38.0
    • View Profile
    • http://lgb.hu/
Re: Wiznet 5100/5300 /etc and Enterprise
« Reply #95 on: 2015.July.06. 15:24:34 »
Ah, I guess, I understand what happens. The specifications says that the problem can be noticed if w5300 is NOT used to transmit data, but only receiving, thus if buffer is full (we are not enough fast to process) the sender is not notified about the window size change too much. I guess later it will "recover" but it's up to the sender than it tries again and a longer time of "stalling" period can be noticed. The code example - as far as I can understand - is about the situation when w5300 only receives. So it can transmit a byte without too much problem for notification as the target won't use that as application data (eg not interested in it). But I am still not 100% sure how they mean that anyway :) But one thing is clear: for "normal" bi-directional tcp stream that code wouldn't work, or well let's say it would work, just it would corrupt the data communication with extra unwanted byte sent :)

Btw, that example is at page 98 ... Maybe we read not the very same spec :)

Offline edoz

  • EP fan
  • *
  • Posts: 125
  • Country: nl
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 39.0 Firefox 39.0
    • View Profile
Re: Wiznet 5100/5300 /etc and Enterprise
« Reply #96 on: 2015.July.10. 11:11:47 »
Hey Guys,

Prodatron created this movie! and it would be a big motivator to have the network ready for the Enterprise :D


https://www.youtube.com/watch?v=L3arrALdYcU
Have fun with the Z80!

Online Zozosoft

  • EP addict
  • *
  • Posts: 13335
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 38.0 Firefox 38.0
    • View Profile
    • http://enterprise.iko.hu/
Re: Wiznet 5100/5300 /etc and Enterprise
« Reply #97 on: 2015.July.10. 12:03:01 »
Wow! :ds_icon_cheesygrin: