Shop OBEX P1 Docs P2 Docs Learn Events
Wiznet W5100 Prelim Drivers Posted - need some reviewers of code/testers — Parallax Forums

Wiznet W5100 Prelim Drivers Posted - need some reviewers of code/testers

Timothy D. SwieterTimothy D. Swieter Posts: 1,613
edited 2010-07-28 23:04 in Propeller 1
I've posted an SPI and an Indirect/Parallel driver for the Wiznet W5100 IC. The drivers are hosted in the OBEX and below are the links. Parallax has hired me to work on the Spinneret Web Server software and these drivers are the stepping stones to building up of another awesome Parallax project. While creating this project we need community testing and feedback. I have a couple immediate needs:

The first need is that there is a bug in the UDP send/receive code in the posted drivers. I believe the problem to be in the SPIN section that handles the sending and receiving of the UDP data when the buffer wraps around. The problem occurs in both drivers. Can someone take a look at the code and perhaps even test it and see if you can identify the problem portion of the code? Here are the notes from some tests that I did.

First test: see if SPI has a problem receiving multiple 1000 byte packets. Using PropNet and SPI/UDP demo. All hardware powered off and back on before test. Buffer set at 2K default size. The sent/received is from the program I used on the PC to send/receive packets. The PropNet was simply echoing data.
○ 1st packet - OK. Sent and received are equal.
○ 2nd packet - OK
○ 3rd packet - NOT OK. Sent 1000 (3000 total). Received 952 (2952 total). Lost 48 bytes.
○ 4th packet - OK. Sent 1000 (4000 total). Received 1000 (3952 total).
○ 5th packet - NOT OK. Sent 1000 (5000 total). Received 856 (4808 total). Lost 144 bytes.

Second test: see if Indirect has the same problem and results as above test.
○ 1st packet - OK. Sent and received are equal.
○ 2nd packet - OK
○ 3rd packet - NOT OK. Sent 1000 (3000 total). Received 952 (2952 total). Lost 48 bytes.
○ 4th packet - OK. Sent 1000 (4000 total). Received 1000 (3952 total).
○ 5th packet - NOT OK. Sent 1000 (5000 total). Received 856 (4808 total). Lost 144 bytes.

Another test I did, and I am not sure if it is related, was to test how large of a packet the W5100 would receive. The buffers were at default size of 2K, but it appears that the W5100 wouldn't receive a packet larger than 1472 bytes. The LEDs for rx activity blinks, but there isn't any feedback to the Propeller on receiving a package. Here are the tests I did:

Other test: Buffer set at 2K default size.
○ Tried sending 1992 bytes - no response
○ Tried sending 1991 bytes - no response
○ Tried sending 1900 bytes - no response
○ Tried sending 1800 bytes - no response
○ Tried sending 1600 bytes - no response
○ Tried sending 1500 bytes - no response
○ Tried sending 1475 bytes - no response
○ Tried sending 1473 bytes - no response

○ Tried sending 1472 bytes - a response (Why? Note that W5100 adds 8 bytes to the UDP packet with various info, so reading from a W5100 this is a 1480 byte packet of which 1472 is payload)
§ 1st packet - OK.
§ 2nd packet - NOT OK. Sent 1472 (2944 total). Received 896 (2368 total). Lost 576.
○ Tried sending 1470 bytes - a response
§ 1st packet - OK.
§ 2nd packet - NOT OK. Sent 1470 (2940 total). Received 892 (2362 total). Lost 578.
○ Tried sending 1465 bytes - a response
§ 1st packet - OK.
§ 2nd packet - NOT OK. Sent 1465 (2930 total). Received 882 (2347 total). Lost 583.
○ Tried sending 1450 bytes - a response
§ 1st packet - OK.
§ 2nd packet - NOT OK. Sent 1450 (2900 total). Received 852 (2302 total). Lost 598.
○ Tried sending 1400 bytes - a response
§ 1st packet -OK.
§ 2nd packet - NOT OK. Sent 1400 (2800 total). Received 752 (2152 total). Lost 648.

Another way the community can help out is to start using the driver. A couple people have and I value their feedback. There are more basic functions to be included in the driver, and maybe some speed performance enhancements as well. I will work in the feedback as the project progresses. I'm eager to cleanup this buffer problem so I can finish testing UDP and move on to TCP testing.

I'll post driver updates to the exchange and keep this thread moving. Any feedback regarding the W5100 drivers please leave it here or PM me.

Drivers and UDP Echo Demo:
SPI: obex.parallax.com/objects/614/
Indirect: [noparse][[/noparse]url]http://obex.parallax.com/objects/615/[noparse][[/noparse]url]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com

Comments

  • Ding-BattyDing-Batty Posts: 302
    edited 2010-06-13 17:03
    Re: the 1472/1480 byte issues -- you may want to look into the MTU (Maximum Transmission Unit) settings for the PC and the W5100 -- the device may not do packet disassembly/reassembly if the data packet is too big for the MTU.

    Windows XP has a default MTU of 1480 (see help.expedient.com/broadband/mtu.shtml#winxp for more info).

    Now why it might be losing bytes (packet too small) might be also due to MTU issues -- have you determined if there is a packet size for which data is echoed correctly? If so, what is the largest packet size that works?
  • TimmooreTimmoore Posts: 1,031
    edited 2010-06-13 19:22
    Without increasing the ethernet MTU is 1518, ethernet header/trailer is 18, IP header is 20 bytes, UDP header is 8 bytes so the largest payload per UDP packet is 1472 unless you support UDP fragmentation (which I do not recommend).

    you dont say if the PC is windows but if its a MTU problem, you can test it by increasing the MTU on the windows machine. You need to go to the NIC properties - depends on the OS version but propably start ->right click network ->properites or connections. (on win7 then change adapter settings)
    Then right click on the LAN adapter and select properites, then configure
    Then advanced (its a NIC feature) then its dependent on the NIC driver but propably Jumbo frame or MTU -> select a larger size


    The MTU is very dependent on the NIC either end and on the network between, ethernet mtu is common but 576 is the max that will always work, though I have never had a problem with ~1400. TCP checks and adjusts but UDP doesn't unless you do it explicitly. Be cafeful getting too close to the MTU size - I have seen software that tunnels (e.g. VPN) that doesn't adjust the MTU but adds headers to the packets and if you send at the MTU size causes packets to be dropped
  • Timothy D. SwieterTimothy D. Swieter Posts: 1,613
    edited 2010-06-13 23:13
    Thank you Ding-Batty and Tinmoore for your insights. I was thinking the 1480 limit was due to my Propeller Software or W5100 setttings/capability, but it appears that it may simply be the MTU settings in Ethernet. This hadn't dawned on me until you guys pointed this out. Sometime ago I recall reading about MTU, but at that time didn't log the thought to recall it for my maximum packet size transmission checking. I think you guys nailed it.

    I am working from a Win XP machine. I'll try changing of the frame size or MTU settings and report back. I suspect this will explain the 1480/1472 behavior I am seeing. It is great to understand that!


    Last night I was still reviewing the UDP Buffer settings which doesn't appear to be working right on rollover of the buffer. Marko, another forum member, was helping me on Skype think through somethings. We didn't find the smoking gun, but have a couple clues to go on. Tuesday I plan to return to the code to continue to investigation.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Timothy D. Swieter, P.E.
    www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
    www.tdswieter.com
  • Timothy D. SwieterTimothy D. Swieter Posts: 1,613
    edited 2010-06-15 10:45
    Good news - the UDP buffer problem is fixed!!! Thanks to Marko for working with me over Skype and e-mail to resolve the problem. He found the problem when my eyes were blind. I'm going to do some TCP testing and other enhancements before I post the update on the OBEX. The problem was located in the txUDP portion of the code and the algorithm was modifying a variable (payloadsize), but then in the next line of code payloadsize was being used inappropriately. rxUDP was correct, so I copied that algorithm as Marko suggested and ba-da-bing - no more lost bytes in UDP.

    After doing some further reading on the MTU, I am absolutely sure you guys are correct and that is why I see that packets over 1472 (+8) don't go through. At a later point I will verify that by adjusting my laptops setting.

    Back to coding and testing for tonight.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Timothy D. Swieter, P.E.
    www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
    www.tdswieter.com
  • edlikestoboogieedlikestoboogie Posts: 71
    edited 2010-07-25 00:28
    Hey Tim,

    I am eager to try your new indirect driver, but I noticed in your obex entry, you mention a version 0.6, but I only see a version 0.5 in the downloaded spin file. Brilldea_W5100_Indirect_Driver_Ver005.spin. Is the version 0.6 available?

    thanks,
    Ed.
  • Timothy D. SwieterTimothy D. Swieter Posts: 1,613
    edited 2010-07-28 07:53
    Thanks Ed! and sorry for taking so long to reply. It appears that I updated the text of the object description in the OBEX, but didn't upload the right file. I just updated the file, please verify that all is there now correctly.

    What is your application you are working on?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Timothy D. Swieter, P.E.
    www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
    www.tdswieter.com
  • edlikestoboogieedlikestoboogie Posts: 71
    edited 2010-07-28 23:04
    Uhm, a water quality sensor system that runs off Ethernet. I see your 0.6 version of the driver. Nice, thanks Tim for the hard work.
Sign In or Register to comment.