Wiznet W5500 support

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...
 
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?
 
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.
 
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.
 
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.
 
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
 
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.
 
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?
 
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!
 
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);
 
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.
 
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.
 
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:
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.
 
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
 
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-Wiz850io-no-handle-of-multicast-and-no-answer-to-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
 
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:
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:
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/blob/master/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
w5x00.png
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:
@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.
 
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
 
Back
Top