Forum Rule: Always post complete source code & details to reproduce any issue!
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 51 to 75 of 86

Thread: Wiznet W5500 support

  1. #51
    Senior Member
    Join Date
    Nov 2012
    Location
    Salt Lake City, UT, USA
    Posts
    258

    sstaub Ethernet3 - fork or merge back to Ethernet?

    Could @sstaub Ethernet3 be done as pull requests to Paul's Teensy Ethernet library? Just asking since I am working on Ethernet for a commercial product and need to pick which of the many T3 MAC address libs to use now and going forward, as well as other Ethernet services such as NTP. It would be nice to not have too much fragmentation or forking of Ethernet functions most people will need. Thanks to everyone for all this helpful code and info...

  2. #52
    Senior Member Epyon's Avatar
    Join Date
    Apr 2013
    Location
    Belgium
    Posts
    443
    Doesn't it seem overkill to pull in a complete library just to read out some register in the Teensy? Getting the MAC is like ten lines of code. Also, isn't NTP already present in the Time library?

  3. #53
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,969
    Quote Originally Posted by bboyes View Post
    Here is the repo with all my test code and docs: https://github.com/systronix/W5500_Test Thanks!
    There isn't a public API to query the chip type. But that info is stored in a private variable, so you could pretty easily add a function to read it.

    I see 5 sketches on your repository. If I were to try to reproduce this problem here, which of those 5 would be best to try first? DhcpStressTest-T3.ino looks like the most promising name. Do I need to run any other program or server, other than a regular DHCP server for my network and the Arduino Serial Monitor to view results?

    Try to imagine a very long list of issues that have accumulated over the last couple months while I've poured all my dev time into USB host, so in a few weeks I'll be going through them as quickly as possible. Any that require fiddling or guesswork are likely to go instantly to the back of the queue.

  4. #54
    Quote Originally Posted by bboyes View Post
    Could @sstaub Ethernet3 be done as pull requests to Paul's Teensy Ethernet library? Just asking since I am working on Ethernet for a commercial product and need to pick which of the many T3 MAC address libs to use now and going forward, as well as other Ethernet services such as NTP. It would be nice to not have too much fragmentation or forking of Ethernet functions most people will need. Thanks to everyone for all this helpful code and info...
    I think that is not a good idea, the library from paul is extremely different from mine, which is based on the classic libraries from arduino.
    Maybe that paul will implement some of the features like PHY support.

  5. #55
    Senior Member
    Join Date
    Nov 2012
    Location
    Salt Lake City, UT, USA
    Posts
    258
    Quote Originally Posted by PaulStoffregen View Post
    I see 5 sketches on your repository. If I were to try to reproduce this problem here, which of those 5 would be best to try first? DhcpStressTest-T3.ino looks like the most promising name. Do I need to run any other program or server, other than a regular DHCP server for my network and the Arduino Serial Monitor to view results?
    Thanks for the fast response! Sorry I wasn't more clear. The DhcpStressTest-T3.ino is a good test case. It's running like a champ on the W5500. It includes code to recover from the ARP/DHCP bug in the W5200.

    It appears I have at least one wounded WIZ820io. I tried some other modules and they work as expected. That's what I get for changing more than one thing at a time - hard to isolate the problem child.

  6. #56
    Senior Member
    Join Date
    Nov 2012
    Location
    Salt Lake City, UT, USA
    Posts
    258
    Quote Originally Posted by Epyon View Post
    Doesn't it seem overkill to pull in a complete library just to read out some register in the Teensy? Getting the MAC is like ten lines of code. Also, isn't NTP already present in the Time library?
    @Epyon fine questions:

    On the library, maybe, but I want to use the same code across multiple projects and multiple Teensy types and only maintain a single copy, so a library seems like a good idea. There's no code penalty, right?

    NTP in Time: you mean http://playground.arduino.cc/Code/Time? It refers to https://www.arduino.cc/en/Tutorial/UdpNtpClient which looks like the example Time>TimeNTP which is the code I am using as a starting point. It has quietly stopped a couple of times when left running overnight, as part of my 'Teensy Test Farm'. I suspect it may be because the DHCP lease renewal failed and the NTP example has no recovery from that (my DhcpStressTest does and has not failed in weeks of running in which I get over a year's worth of typical DHCP lease renewals in 24 hrs). So I am in process of making TimeNTP more robust. Sometimes also the NTP server doesn't respond (not surprising, it must get millions of requests in an hour) and I just discovered http://www.pool.ntp.org/zone/us

  7. #57
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,969
    Quote Originally Posted by Epyon View Post
    Doesn't it seem overkill to pull in a complete library just to read out some register in the Teensy?
    I suppose the answer depends on what resources you consider to be expensive and in limited supply. Perhaps that's bytes of memory and CPU cycles? Or maybe it's hours & minutes of human attention. Or maybe long-term code maintenance & minimizing risk of breaking when other code changes weigh heavily.

  8. #58
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,969
    Quote Originally Posted by sstaub View Post
    Maybe that paul will implement some of the features like PHY support.
    I might. Are these well documented somewhere? Or are good examples published? Is anyone else actually using them yet?

  9. #59
    You can find the code on https://github.com/sstaub/Ethernet3, there are also some small examples.

  10. #60
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,969
    I recently made an attempt to implement a workaround Wiznet recommends for W5100 errata regarding ARP and subnet mask. I've been told the errata applies to W5200, but not W5500.

    It's on this branch.

    https://github.com/PaulStoffregen/Ethernet/tree/errata

    So far, I haven't found a way to actually test if this makes any difference at all. Anyone have any ideas?

  11. #61
    Hi all,

    This might be a little off-topic but I'm trying to find out whether the wiz850io could be used with teensy++ 2.0 reliably - given the available library. Anyone have any ideas?

  12. #62
    Junior Member
    Join Date
    Nov 2016
    Posts
    5
    Hope this is the right place for this reply. I have been trying to solve a watchdog issue with EthernetClient.connect() on the wiz850. For now, I have lengthened my watchdog timeout, and I believe it has solved my problem. I still believe the better solution is to have .connect() fail faster.

    From what I can find, retransmission count (RCR) and timeout (RTR) cannot currently be set on the w5500 chip using the Ethernet Library. I looked into what it would take to modify the libraries to add this function and found the appropriate register on the w5500 datasheet, but I am still a bit "green" on these kind of in-depth modifications and I am confused about how to write directly to the w5500.

    Any help is appreciated.

    Thanks!

  13. #63
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,789
    looks like RCR and RTR are defined in w5100.h
    inline void setRetransmissionTime(uint16_t timeout) { writeRTR(timeout); }
    inline void setRetransmissionCount(uint8_t retry) { writeRCR(retry); }

    so to your sketch you might add:

    #include <w5100.h>
    ...
    W5100.setRetransmissionCount(n);

  14. #64
    Junior Member
    Join Date
    Nov 2016
    Posts
    5
    Quote Originally Posted by manitou View Post
    looks like RCR and RTR are defined in w5100.h
    inline void setRetransmissionTime(uint16_t timeout) { writeRTR(timeout); }
    inline void setRetransmissionCount(uint8_t retry) { writeRCR(retry); }

    so to your sketch you might add:

    #include <w5100.h>
    ...
    W5100.setRetransmissionCount(n);
    I had previously tried to add setRetransmissionCount(n);
    To the w5100.cpp file and it failed to compile so I assumed that register wasn't defined for the w5500. Your suggestion compiled and seems to be working, but my issue with the server is pretty intermittent so it is difficult to test if the time out has actually taken effect. Time will tell.

    Thanks for the help.

  15. #65
    A new version of the Ethernet3 library (1.4) with many small features is published on https://github.com/sstaub/Ethernet3

  16. #66
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,969
    Sadly, it seems this version chose to use the same function name init() which Adafruit used on their fork, but for a completely different purpose. This one uses a much more descriptive name, which is good. But since Adafruit has tremendous reach in the Arduino world, different functionality for the not-so-descriptive init() function is bound to cause confusion.

  17. #67
    Quote Originally Posted by PaulStoffregen View Post
    Sadly, it seems this version chose to use the same function name init() which Adafruit used on their fork, but for a completely different purpose. This one uses a much more descriptive name, which is good. But since Adafruit has tremendous reach in the Arduino world, different functionality for the not-so-descriptive init() function is bound to cause confusion.
    I know about the fact that Adafruit uses the init function. But the intention for this library is not to extend the 'Arduino' library with new functionality, it is to do things more intuitiv and logical. So, also the Ethernet.begin procedure is incompatible because the arduino style is very stupid, so I want to change these things also in the future, e.g. i will rename in a future release the stop() function with close(). But feel free to take the ideas to your library.
    Last edited by sstaub; 06-10-2017 at 02:37 PM.

  18. #68
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,836
    Has anybody had success are receiving UDP broadcast on a W5500 via the ethernet library?

    Seem to be only seeing directly addressed packets at the moment, unsure if it's just the way things are or if I've missed the magic incantation.

  19. #69
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,789
    Quote Originally Posted by GremlinWrangler View Post
    Has anybody had success are receiving UDP broadcast on a W5500 via the ethernet library?

    Seem to be only seeing directly addressed packets at the moment, unsure if it's just the way things are or if I've missed the magic incantation.
    I don't have W5500, but confirmed w5200 receives UDP broadcast. my mask is 255.255.255.0 and sender sends to 192.168.1.255, and my w5200 sees it.

    you could verify with wireshark or tcpdump that your broadcast is going out properly on the ether.
    IP 192.168.1.4.60607 > 192.168.1.255.8888: UDP, length 1000

  20. #70
    Quote Originally Posted by GremlinWrangler View Post
    Has anybody had success are receiving UDP broadcast on a W5500 via the ethernet library?

    Seem to be only seeing directly addressed packets at the moment, unsure if it's just the way things are or if I've missed the magic incantation.
    https://forum.pjrc.com/threads/45365...o-ARP-messages

    have a look here, I think I had the same the same issue.
    I don't remember if I changed something but now seems to work properly,
    try to recompile and use the full Ethernet.begin(mac, ip, dns, gateway, subnet), then should be working

  21. #71
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,836
    Ethernet with W5500 and UDP broadcasts

    When all else fails install tcpdump. Seems my test setup of two Pi's was not sending broadcast packets at all due combination of things not capable of broadcast,permissions and not reading the manual.

    For anybody else arriving via google, on my Pi's I wasn't able to find a command line method to send UDP broadcasts without installing extra stuff, and if using node-red there is a special drop down box to change to broadcast along with setting actual address.

    Did some more testing and using my Arduino 1.6.1.1 install the standard teensyduino ethernet library happily captures broadcasts, both with the full(mac,ip,dns,gateway,subnet) and the default (mac,ip) begin statements, had run across the same advice as lorenzafattori gave that you needed to declare a subnet for broadcast to work but that didn't appear to be the case here - YMMV (especially if not on 192.168.1.x).
    Last edited by GremlinWrangler; 07-31-2017 at 01:57 PM. Reason: subnet clarification

  22. #72
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,789
    For BSD sockets, you need to enable the BROADCAST socket option. FWIW, here is a little python to broadcast UDP
    Code:
    from socket import *
    import time
     
    ECHO_BCAST = '192.168.1.255'
    ECHO_PORT = 8888
    
    buff = bytearray(1000)
     
    sock = socket(AF_INET, SOCK_DGRAM)
    sock.setsockopt(SOL_SOCKET, SO_BROADCAST, 1)
     
    for i in range(4):
        sock.sendto(buff, (ECHO_BCAST, ECHO_PORT))
        time.sleep(.1)
    Last edited by manitou; 08-01-2017 at 11:48 AM.

  23. #73
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,789
    I purchased a W5500, FWIW, here are numbers comparing w5200 with w5500

    Code:
      Teensy 3.2@120mhz SPI clk 30mhz  W5200  vs W5500  8/7/17  4K buffers
                      W5200   W5500
      UDP echo(us)       79      73     8-byte RTT
      UDP send(mbs)      17      19     1000-byte UDP pkts
      UDP recv            3       3
      UDP pps         21220   23246     8-byte UDP pkts
      TCP send           14      15
      TCP recv           24      24
      buffer write/read (mbs)  22.57/27.13  27.13/27.04
    more numbers at https://github.com/manitou48/DUEZoo/...er/wizperf.txt

    wiznet power
    Code:
    what the data sheets say:
                w5100  146 ma (max 183)
                w5200  160 ma (max 175)
                w5500  132 ma
    Here are my measurements, sampling current to wiznet module every 100 ms
    Click image for larger version. 

Name:	w5x00.png 
Views:	48 
Size:	34.3 KB 
ID:	12057
    The T3.2 is powering the wiznet module from 3v3, and after the T3.2 starts up, the sketch does a TCP transfer for about 5 seconds. Three different tests are plotted on the same graph. See more WiFi/Ethernet power graphs
    Last edited by manitou; 01-31-2018 at 09:27 PM.

  24. #74
    Senior Member
    Join Date
    Nov 2012
    Location
    Salt Lake City, UT, USA
    Posts
    258
    @manitou Interesting how close those numbers are. For me the W5500 main draws are
    1. No ARP bug (which affects DHCP of course)
    2. Lower cost
    Hopefully W5500 does not have other new bugs.
    I did see the ARP bug in W5200 (WIZ820io) where sometimes DHCP address would become 0s. I was able to patch around it with some success. But, given the W5500 is less expensive too...

    Also I bought some of the WIZ850io Chinese cheapos on eBay. So far they all work fine. They appear to use the real WIZnet W5500 chip (the alternative, rolling your own, would cost a lot, so why bother), and how complicated can adding magnetics and a socket be, using the WIZnet reference design? So for personal use, OK. In client and OEM products I will pay the WIZnet price.

  25. #75
    Really similar numbers but for now the W5500 is the best option for price and performance... hoping to see the in-built ethernet of teensy 3.5/3.6 available in future

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •