Welcome, Guest. Please login or register.


Author Topic: Wiznet 5100/5300 /etc and Enterprise (Read 11429 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 #60 on: 2015.July.05. 00:20:27 »
ok, I won't, I hadn't read that example! :oops:

Don't worry, I can't see clearly that specified strict read order of IDM_DR0 and IDM_DR1 does not change as well, or FS bit is usable at all in 8 bit mode (DBS is not, it seems). Just guessing ... But the example shows that it's quite OK even in the normal (non-FS) mode ...

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 #61 on: 2015.July.05. 09:45:06 »
Regarding fast data transfer:
That was my first thought if auto-incrementation would work:

Hmm, I guess you wanted to exchange every two bytes but it's not needed. So I guess, that's enough:

Code: ZiLOG Z80 Assembler
  1.   LD  C, IDM_AR0_EP_PORT_ADDRESS  ; *** EP I/O address of IDM_AR0 which is IOB + 2
  2.   LD  HL, register_number_of_the_fifo_register
  3.   OUT (C), H ; w5300 byte order: you need to specify the high byte of the register number first, so H of HL
  4.   INC C       ; C now for IDM_AR1 (IOB + 3)
  5.   OUT (C), L ; write low byte of regnum to IDM_AR1
  6.   INC C   ; now C for IDM_DR0, what we need in the loop exactly (IOB + 4)
  7.   LD  HL, buffer_to_store_RX_data_to    ; it is not needed to be 256 byte aligned
  8. THE_LOOP:     ; some unrolled loop for perforamce (just an example)
  9.   INI     ; C points to IDM_DR0 (@ IOB+4)
  10.   INC C
  11.   INI     ; C points to IDM_DR1 (@ IOB+5)
  12.   DEC C
  13.   INI     ; C points to IDM_DR0 (@ IOB+4)
  14.   INC C
  15.   INI     ; C points to IDM_DR1 (@ IOB+5)
  16.   DEC C
  17.   ... etc ... etc ...

As far as I can see (from code examples in datasheet) for 8 bit FIFO transfer, bytes are still in the "good order", eg, reading the network packet contain "abcde" would result in the following scheme:

Code: [Select]
IDM_DR0 reads as "a"   (always start with IDM_DR0!!)
IDM_DR1 reads as "b"
IDM_DR0 reads as "c"
IDM_DR1 reads as "d"
IDM_DR0 reads as "e"
IDM_DR0 reads as SOMETHING, since always _even_ number of transfer needed, but in our case you need to ignore this byte but you MUST read it!

This also means that you need always start with IDM_DR0 and end with IDM_DR1 and you must be careful to use this strict "altering" method of using I/O ports, so w5300's internal counter in buffer won't go mad (as it would use that for 16 bit ops, but we use w5300 in 8 bit mode!).

Actually, this can be surprising because of the opposite byte order of w5300 what we're used with Z80, but still, RX/TX FIFO stuffs seems to be "the right order". This is because (I think!) giving eg network port, it's a 16 bit value, so it's really high byte FIRST, then low byte, but TX/RX buffers DOES NOT contain 16 bit values, but 8 bit bytes! So maybe byte order simply does not apply here too much because of the nature of byte grained data. Still, the bus interface of w5300 is 16 bit oriented with "8 bit mode hack" so you need to access this altering order of ports and always even numbers (which would be natural in 16 bit I/O + bus mode).

What is also important still: if there is even number of bytes to be read/written, there is nothing special. If you need odd number of bytes, then you need to read one more bytes to be even number (and ignoring the last byte), or send a dummy byte if it's a write op for TX FIFO. That's natural, as w5300 expect word I/O, so for 8 bit I/O it's n * 2 ops of 8 bits (n would be the number of 16 bit I/O ops needed), thus it is always even number of 8 bit ops then as n * 2 for any n is always even!

Again, this is my understanding of the situation! It can be wrong ...
« Last Edit: 2015.July.05. 14:06:18 by lgb »

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 #62 on: 2015.July.05. 12:41:27 »
Ok, I've decided to try to be sure about the situation, and what I found:

Code: C
  1.   *((vuint8*)IDM_AR0) = Sn_TX_FIFOR0(s);
  2.   *((vuint8*)IDM_AR1) = Sn_TX_FIFOR1(s);
  3.   for (idx = 0; idx < len; idx+=2) {
  4.     *((vuint8*)IDM_DR0) = *((uint8*)(buf+idx));
  5.     *((vuint8*)IDM_DR1) = *((uint8*)(buf+idx+1));
  6.   }

This is code fragment from the "driver" of w5300 written by Wiznet (for AVR MCUs, but who cares what, if it's C). What is interesting here, that it seems the theory is OK, they do what we exactly want to do. This is writing TX buffer, you see, IDM_AR is set up for the FIFO TX register number ofr the given socket, then using only IDM_DR0 and IDM_DR1 to transfer. AVR is also 8 bit, so it's a good example for us, also since the driver is written by Wiznet, I assume they know it would work this way :) You see, "buf" is read "linearly" just outputting to TX FIFO registers with IDM_DR0, IDM_DR1, IDM_DR0, IDM_DR1 ... order. The example above is for writing (TX buffer) for sure for reading it is similar but for the RX FIFO and storing read data, of course. The C loop is written this way (with idx incremented by too, and then refer for idx and idx+1) I guess to automatically handle the situation of given odd number of bytes to be written, to always transfer even number of bytes even in that case.

Knowing this, I would say, the Z80 example - I wrote in my previous post - should be OK that way! So I can be proud that I could interpret the data sheet well ... haha.

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 #63 on: 2015.July.05. 13:34:52 »
Great, thanks LGB and Bruce for the clarification! These are good news, transfering data will be very fast!
I am currently working on the DHCP implementation, but as soon as it makes sense I can start with the W5300 driver for the Enterprise.

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 #64 on: 2015.July.05. 14:15:19 »
Great, thanks LGB and Bruce for the clarification! These are good news, transfering data will be very fast!
I am currently working on the DHCP implementation, but as soon as it makes sense I can start with the W5300 driver for the Enterprise.

Hmm. I guess you mean a generic (not only SymbOS/EP but for any SymbOS platform) implementation. For EP, I think: if EPNET has decent EXOS support it would be more the task of the EXOS to set MAC, IP, etc.  Since anyway, maybe not only SymbOS want to utilize EPNET :) And because SymbOS would (?) use EXOS anyway in the loader to get IOB for example, a successful answer can mean that IP settings of the EPNET are already initialized? I am not sure about this, what Bruce think: should EPNET ROM set (or even DHCP) IP at "boot" time so EPNET is ready to be used for TCP/IP already, or it will be the job of the app, or at least the user (to issue some EXOS commands to do it even from IS-BASIC like :NET IP DHCP or whatever ...).  But I think SymbOS needs generic, SymbOS-platform-independent DHCP implementation anyway user can modify settings also other platforms may not have this job done already, etc etc ...

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 #65 on: 2015.July.05. 14:27:32 »
But I think SymbOS needs generic, SymbOS-platform-independent DHCP implementation anyway user can modify settings also other platforms may not have this job done already, etc etc ...
Yes, exactly. As soon as there is EXOS support for EPNET it makes sense to set the IP and DNS config there (including DHCP usage).
On the MSX there is a tool for MSX-DOS for this task as well, but it is optional.
The Amstrad CPC probably won't have this (at the beginning).
So it's necessary to have it in SymbOS, too. DHCP is a nice "nice to have" feature :) but it makes the whole solution more completed.

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 #66 on: 2015.July.05. 14:38:56 »
I already took a look on the DHCP protocol some weeks ago, hmm, it's multiple-time rounds between the client and the server, it sounded a bit complicated at the first glance. But it seems I have to "emulate" a DHCP server somehow, as for Xep128 will emulate w5300 using native TCP/IP by the host OS (the OS which runs the emulator, ie Linux or Windows for example). So from the point of the real LAN and host OS, it does not make any sense to send a real DHCP to the network as the host OS already has IP ... So what I thought is to check the sent packets by the emulated w5300 and if it is founded to be DHCP related, I fake an answer from Xep128. So apps in Xep128 would think it's a real ethernet network and it talks to the DHCP server and it can get an IP ...

Offline BruceTanner

  • EP user
  • *
  • Posts: 485
  • 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 #67 on: 2015.July.05. 14:58:41 »
Nice find lgb - thanks for that, that clarifies it! INI, INC/DEC C is still one T faster than one INIR interation so maybe not *quite* as fast an an "unrolled" plain INIR but I can certainly live with that!

Yes I agree, I would hope DHCP could be done at startup by the EXOS device/code but there is probably a case for being able to set the subnet, ip etc manually too, even if just for testing (the w5300 really ought to doing the DHCP stuff!). I am now wondering whether the "use DHCP y/n" setting and the manually-set subnet & ip should be stored in flash along with the MAC address.

It might be a bit of pain as I'm not using interrupts - might have to have an EXOS timer interrupt and do it from there. The alternative is to do it synchronously on the first application EXOS call.

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 #68 on: 2015.July.05. 15:10:42 »
Yes I agree, I would hope DHCP could be done at startup by the EXOS device/code but there is probably a case for being able to set the subnet, ip etc manually too, even if just for testing (the w5300 really ought to doing the DHCP stuff!). I am now wondering whether the "use DHCP y/n" setting and the manually-set subnet & ip should be stored in flash along with the MAC address.

Actually, storing IP settings and MAC in flash is a very nice idea! Just flash is not RAM, maybe you need to erase a whole flash page and rewrite then? It would be cool to put an RTC chip onboard, it can be used for clock source as well of course, and some RTC chips have some dozens of bytes of NVRAM which is cool to be used as config storage, as with the PCs + BIOSes. However as I've written one of my older posts in this topic: it seems w5300 has PHY interface running at its own, no connection with the app in any way. So you can't ask the link status etc, which would be nice to be solved, so it does not make sense to wait for DHCP answer, when there is even no link through the RJ45 connector eg without any cable connected. Other possibility: have a "sub command" of proposed command NET for DHCP and manual IP config (which is a good thing anyway too) and eg put in EXDOS.INI or something, and you can edit whatever you want to be set. Not as nice solution maybe, but more simple, that is the IP settings are stored on disk in some form!

Quote
It might be a bit of pain as I'm not using interrupts - might have to have an EXOS timer interrupt and do it from there. The alternative is to do it synchronously on the first application EXOS call.

Well, I also thought about the EXOS vs w5300 thing, that "events" on w5300 can cause interrupts or you need to wait inside a busy loop. But since EXOS is not a multitask OS, I guess apps should anyway wait ... What is interesting (and I don't know the details neither on EXOS nor with the w5300): if data is received and we can read RX FIFO I guess we must (?) read the whole byte stream (packet data?) received, but EXOS function may ask for a single byte to read only! What happens then? Should we have a buffer in EP too for EXOS to store received bytes, in case if EXOS app wants to read less bytes only? How the RAM needs of EPNET ROM is handled? It seems the designers of the SD card cartridge worried about allocating RAM from the system segment, as many apps are picky to have shortened amount of "base" RAM or at least system segment free space. So they built SRAM onto the cartridge not for general use, but mainly for usage by the SDEXT ROM code itself. If I understand the situation correctly, at least. So, with EPNET card, if I remember correctly you mentioned it will contain RAM too. Is it for this purpose exactly like with the SD stuff?

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 #69 on: 2015.July.05. 15:25:15 »
I already took a look on the DHCP protocol some weeks ago, hmm, it's multiple-time rounds between the client and the server, it sounded a bit complicated at the first glance. But it seems I have to "emulate" a DHCP server somehow

DHCP implementation had quite a low priority for me, as it is only a luxury feature for lazy users :D It is not important, as you can use a fixed IP/DNS configuration.
But the protocol seems to be quite easy. The reason for sending two packets on both sides (discover ->, offer <-, request ->, <- acknowledge) is probably the fact, that you can have more than one DHCP server in your local network, and the client has to make a choice after the discovery stage and tell its decission to all others.

if data is received and we can read RX FIFO I guess we must (?) read the whole byte stream (packet data?) received, but EXOS function may ask for a single byte to read only! What happens then? Should we have a buffer in EP too for EXOS to store received bytes, in case if EXOS app wants to read less bytes only?

No, that's not necessary. You can read less bytes than received from the RX buffer, you will just update the buffer pointer then in the correct way. The only thing I wonder is, if you always have to read and skip even number of bytes from the buffer because of the 16bit issue.

Regarding DHCP/DNS and interrupts: These operations work usually quite fast, so maybe you could stay in the routine until the process is finished. In SymbOS I poll the network hardware every 1/50second, which works fine as well.

Offline BruceTanner

  • EP user
  • *
  • Posts: 485
  • 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 #70 on: 2015.July.05. 16:03:32 »
Yes EPNET has separate RAM just like the SD card, and for the same reason. There is 64k flash in total and the top two 16k segments are "normal". The bottom two 16k segments each have their own 4k RAM area, so really 12k flash+4k RAM. I'm thinking EXDOS in the 32k, EPNET EXOS drivers etc in the first 12k+4k and the remaining 12k+4k spare/overflow or possibly for Compact Flash support code if that proves necessary (although it's pretty similar to IDE so EXDOS might just do it anyway with minor modification). Or could be for storage of addresses etc of all sorts...will see how it goes!

I'm aiming for EPNET to be useful without disks so if the IP address etc has to be set by user commands after each boot that will be a pain! Though that is how I will do "manual configuration".

I'm trying hard to resist "feature creep" so that I stand a chance of getting it finished! My thoughts were that with a network connection a RTC is less important because you can at least use NTP or something to get the date/time from somewhere else.

I assume you do not have to read the whole buffer immediately if you don't want to, but you'll probably have to read it a word at a time, so hold a byte "in hand" for the EXOS device - not too hard. But there should be enough RAM there to buffer it if that turns out to be necessary.

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 #71 on: 2015.July.05. 17:16:31 »
DHCP implementation had quite a low priority for me, as it is only a luxury feature for lazy users :D It is not important, as you can use a fixed IP/DNS configuration.

Yes, but for not-so techy people, I guess this is a must. At the other hand, maybe not my mother will run SymbOS. Or use EP. Or EPNET :)

Quote
No, that's not necessary. You can read less bytes than received from the RX buffer, you will just update the buffer pointer then in the correct way. The only thing I wonder is, if you always have to read and skip even number of bytes from the buffer because of the 16bit issue.

16 bit is an issue, the specification says as something like "it is NOT allowed to access any other w5300 register than low byte of the FIFO if high byte is already accessed before" (that is, in indirect mode: IDM_DR1 must be accessed if IDM_DR0 has been  accessed before, and you can't even set another register to be selected with IDM_AR before you complete a 16 bit access. It seems this strict access method is only for the FIFO registers, others can be accessed for only a "8 bit half" of the register and continue with another register then!). So you must read (or writes) even number of bytes, always. Thus. if app wants odd number of bytes, you still need to buffer (ie in your network daemon, whatever) at least one byte! Of course if it was last byte in RX  buffer, you read two bytes from FIFO but ignore the other (and then not buffer).

Quoted from the specification (page 87):

"If  the host system  uses  8  bit  data  bus  width,  Sn_TX_FIFOR0  and  Sn_TX_FIFOR1  should  be accessed  in  a  pair.  When  copying  1 byte  data  into  internal  TX  memory, the host  writes  the  1 byte data in Sn_TX_FIFOR0 and dummy data in Sn_TX_FIFOR1. Sn_TX_FIFOR should be accessed with 2 byte size. Access the Sn_TX_FIFOR0 of low address register  first, and the Sn_TX_FIFOR1 of high address register. After accessing Sn_TX_FIFOR0, it is not allowed to access other W5300 registers except for Sn_TX_FIFOR1."

Of course, it translates a bit different for indirect mode, since there it means writing IDM_AR to be able to use other register, and IDM_DR1 for the already selected Sn_TX_FIFOR1 for example. Thus, if IDM_AR is set for the Sn_TX_FIFOR and then you accessed for write IDM_DR0 then you _must_ and _can only_ access IDM_DR1 not any other register. As far as I can see. The same for the other direction (RX FIFO reg).

For the RX direction (page 88):

"If  the host system uses  8  bit  data  bus  width,  Sn_RX_FIFOR0  and  Sn_RX_FIFOR1  should  be accessed  in  a  pair  as  like  Sn_TX_FIFOR.  It  is  not  allowed  to  access  Sn_RX_FIFOR0  and Sn_RX_FIFOR1  right  after  accessing  Sn_TX_FIFOR0  and  Sn_TX_FIFOR1.  Theseare  cause for the incorrect read.   In   order   to   prevent   this,   after   reading   Sn_TX_FIFOR0   and Sn_TX_FIFOR1, the host reads any register such as Sn_MR and then access Sn_RX_FIFOR. When the host reads the received DATA packet in internal RX memory through Sn_RX_FIFORby 2 bytes, the low and high data in internal RX memory can be readthrough Sn_RX_FIFOR0 and  Sn_RX_FIFOR1respectively.  The host  performs  RECV  command  after  processing the received DATA packet in internal RX memory. "

So about the same issue but for another direction. What seems to be odd for me, this RECV command ... If reading RX FIFO reg updates w5300 internal pointer stuff etc for the socket RX buffer, what exactly does. I had not so much time to try to analyze this part of the specification yet! Also for RX there seems to be more rules given by the spec, see what I've copied here above. Unfortunately I hadn't much time too much at the weekend, still I would need time to try to understand these. I guess ...
« Last Edit: 2015.July.05. 17:52:43 by lgb »

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 #72 on: 2015.July.05. 19:22:53 »
I'm aiming for EPNET to be useful without disks so if the IP address etc has to be set by user commands after each boot that will be a pain! Though that is how I will do "manual configuration".

Of course I agree, just I have no idea how "difficult" (or not) to modify the flash content from EP.

Quote
I'm trying hard to resist "feature creep" so that I stand a chance of getting it finished! My thoughts were that with a network connection a RTC is less important because you can at least use NTP or something to get the date/time from somewhere else.

Exactly :) I only miss the NVRAM feature of those chips more, if you have network, it's kinda easy otherwise to get the time from time servers ... Maybe it would be a great idea to have some larger NVRAM-like entity created for the EP, so every projects can use it, more like the BIOS settings storage on PCs. Or such ...

Quote
I assume you do not have to read the whole buffer immediately if you don't want to, but you'll probably have to read it a word at a time, so hold a byte "in hand" for the EXOS device - not too hard. But there should be enough RAM there to buffer it if that turns out to be necessary.

Honestly, I am a bit lost here with the specification (of w5300, I mean). Many things are not clear for me, ie it says packet-info word tell the size. But what happens, if multiple packet arrived before we could process? What I can imagine, that if you read FIFO RX you will get packet info which tells the number of bytes in the packet. After reading that, and still bytes in the RX buffer (according to fifo rx size) reading a word will find the next received packet's packet-info word with its length, so I know how many bytes should be read. Well, I think :) What I don't know, where and how RECV command is needed (fromt he spec it seems it is some kind of acknowledgement only that we really read X words, and it has no any other purposes?), and why, if internal counter of RX FIFO "knows" how much data is already transferred to the host (so: EP) from the RX buffer.

The problem here: I need to understand these also for creating my "test app" for EP, but also at a level that I can emulate a w5300 in Xep128, so things like these give me enough headache. And maybe my task is harder this way, compared to the situation that you need only understand w5300 to start to use it, but you don't need to reimplement it (as a form of software emulation ...).

"Of course" the "TCP aligned mode" should be forgotten, as it means that you _know_ always even number of bytes have in received packets? It sounds odd, that how you can be sure ever with that.

Haha, how "funny": it's _odd_ if you know that it's always _even_ :)
« Last Edit: 2015.July.05. 19:49:11 by lgb »

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 #73 on: 2015.July.05. 20:29:31 »
Honestly, I am a bit lost here with the specification (of w5300, I mean). Many things are not clear for me, ie it says packet-info word tell the size. But what happens, if multiple packet arrived before we could process? What I can imagine, that if you read FIFO RX you will get packet info which tells the number of bytes in the packet. After reading that, and still bytes in the RX buffer (according to fifo rx size) reading a word will find the next received packet's packet-info word with its length, so I know how many bytes should be read. Well, I think :) What I don't know, where and how RECV command is needed (fromt he spec it seems it is some kind of acknowledgement only that we really read X words, and it has no any other purposes?), and why, if internal counter of RX FIFO "knows" how much data is already transferred to the host (so: EP) from the RX buffer.
You only have separated packets with own headers in the RX buffer in UDP mode. In TCP mode the whole data is one "stream" (no single packets). At least this is how it works for the W5100.

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 #74 on: 2015.July.05. 20:46:42 »
You only have separated packets with own headers in the RX buffer in UDP mode. In TCP mode the whole data is one "stream" (no single packets). At least this is how it works for the W5100.

Hmm, that sounds odd for me. Because, what happens if you already read the packet info byte from RX buffer describing the data size, but meanwhile new packet arrives? The old packet info cannot be modified as it's already read ... That's why I thought, the new packet is stored then with its own packet-info word in the RX buffer. What I also suspected that the TCP aligned mode is just for that you mentioned: then it's one stream without any packet info in TCP mode.

Ah OK, I got your point now, but I'm afraid it's not so OK with the w5300! Just checked the "w5100 vs w5300" spec from Wiznet. It seems w5100 works like you mentioned, but w5300 does not, and it has (I already known that, that's why I lamented on that in my previous post you answered to) packet info even in TCP mode (not just in UDP, though it's much more simple, only a word for packet size in TCP mode). Unless if you set TCP aligned mode. I think the difference is because w5300 being so much 16 bit organized (and maybe w5100 is not? I don't know). Thus, if TCP data would be one stream with w5300 as you mentioned then there will be problem that an odd sized packet followed by a newer packet you wouldn't know that a byte should be skipped because it's just for the word alignment "dummy" byte. That is exactly what is TCP aligned mode is for: according the specification if you are SURE that only even sized packets received (that's something I find funny, because how you can be sure ...), you can set TCP align mode, and indeed, then it will work as you mentioned: a single stream without header in  TCP mode. Just because of the facts above, I doubt it's useful with that constraint we can't be sure about in a general TCP/IP solution at least (I can imagine that with a specific protocol a designer can make sure about this ...). Or it's also possible that I misunderstood something, of course.

It seems it's kinda handy to read that w5100 vs w5300 comparsion sheet from Wiznet. For me it does not mean too much (as I don't know w5100) but for you, it can be useful (as you are familiar with the w5100 because of the MSX net solution support already written using the w5100).

Anyway, I start to feel that w5100 is "better" for a 8 bit project: more simple. Only you have less sockets (4 instead of 8 ), and less on-chip TX/RX buffer RAM ...
« Last Edit: 2015.July.05. 21:18:48 by lgb »