Add Support for W5500 SPI Ethernet Controller (without multiple devices using the same SPI bus)

[marvincarstensen]

With the upcoming end of support of devices with 4 MB flash on OpenDTU-OnBattery (#1025) there is an upcoming problem with the ethernet support. Currently there is no S3-Version of the WT32-ETH01 and also the S3 doesn't include an Ethernet MAC anymore.

So I started to research alternatives and found the W5500. Based on #1200 I've updated to master and simplified the implementation by e.g. removing the SpiPatcher logic. This way the libraries (NRF + CMT) don't need to be modified.

As a trade-off with this branch it is only possible to connect the W5500 with NRF or W5500 with CMT or NRF and CMT without ethernet. Furthermore because SPI3_HOST is not available on e.g. C3 the W5500 will not work and a warning will be outputted.

Multiple devices using the same SPI bus (implemented in #1200) would be best option for the future, but for now I think this is the fastest way to implement the W5500 without doing changes to other libraries.

I hope we can merge this PR into the master, so that there is an option for S3 + Ethernet in the future.

[D3R-ST3FAN]

I can confirm this PR is working fine withe the Fusionboard and POE Hat.

[D3R-ST3FAN]

@tbnobody any thoughts about this one or #1200

[functionpointer]

I found a weird latency issue with this:

Also visible on linux:

$ ping 10.10.11.240 -i 0.2
PING 10.10.11.240 (10.10.11.240) 56(84) bytes of data.
64 bytes from 10.10.11.240: icmp_seq=1 ttl=64 time=493 ms
64 bytes from 10.10.11.240: icmp_seq=2 ttl=64 time=291 ms
64 bytes from 10.10.11.240: icmp_seq=3 ttl=64 time=89.0 ms
64 bytes from 10.10.11.240: icmp_seq=4 ttl=64 time=894 ms
64 bytes from 10.10.11.240: icmp_seq=5 ttl=64 time=695 ms
64 bytes from 10.10.11.240: icmp_seq=6 ttl=64 time=492 ms
64 bytes from 10.10.11.240: icmp_seq=7 ttl=64 time=290 ms
64 bytes from 10.10.11.240: icmp_seq=8 ttl=64 time=88.8 ms
64 bytes from 10.10.11.240: icmp_seq=9 ttl=64 time=893 ms
64 bytes from 10.10.11.240: icmp_seq=10 ttl=64 time=692 ms
64 bytes from 10.10.11.240: icmp_seq=11 ttl=64 time=493 ms
64 bytes from 10.10.11.240: icmp_seq=12 ttl=64 time=291 ms
64 bytes from 10.10.11.240: icmp_seq=13 ttl=64 time=88.5 ms
64 bytes from 10.10.11.240: icmp_seq=14 ttl=64 time=894 ms
64 bytes from 10.10.11.240: icmp_seq=15 ttl=64 time=691 ms
64 bytes from 10.10.11.240: icmp_seq=16 ttl=64 time=490 ms
64 bytes from 10.10.11.240: icmp_seq=17 ttl=64 time=290 ms
64 bytes from 10.10.11.240: icmp_seq=18 ttl=64 time=87.3 ms
^C
--- 10.10.11.240 ping statistics ---
19 packets transmitted, 18 received, 5.26316% packet loss, time 3690ms
rtt min/avg/max/mdev = 87.260/457.881/894.212/278.671 ms, pipe 5

All pings get answered, but only once per second.
It seems like incoming packets are stored in a buffer, and whatever deals with the packets is only called once per second.
Does anyone else have this issue too?

Edit: This issue does not exist with WiFi. I get pretty consistent 10ms latency with that.

[functionpointer]

Classic ESP32 also has SPI3, right? Also there is a typo here

[stefan123t]

Classic ESP32 Wroom only has HSPI and VSPI, ie two SPI Busses 🚌 according to my memory.

[functionpointer]

The ESP32 integrates 4 SPI peripherals: SPI0, SPI1, SPI2 (commonly referred to as HSPI), and SPI3 (commonly referred to as VSPI).

Source

This code doesn't make use of two SPI buses. If CMT2300A is configured, it just gives up.

And sure enough, when I edit it to use SPI3_HOST it works just fine. On classic ESP32 (I used ESP32 mini)

[functionpointer]

I found a weird latency issue with this:

Also visible on linux:

$ ping 10.10.11.240 -i 0.2
PING 10.10.11.240 (10.10.11.240) 56(84) bytes of data.
64 bytes from 10.10.11.240: icmp_seq=1 ttl=64 time=493 ms
64 bytes from 10.10.11.240: icmp_seq=2 ttl=64 time=291 ms
64 bytes from 10.10.11.240: icmp_seq=3 ttl=64 time=89.0 ms
64 bytes from 10.10.11.240: icmp_seq=4 ttl=64 time=894 ms
64 bytes from 10.10.11.240: icmp_seq=5 ttl=64 time=695 ms
64 bytes from 10.10.11.240: icmp_seq=6 ttl=64 time=492 ms
64 bytes from 10.10.11.240: icmp_seq=7 ttl=64 time=290 ms
64 bytes from 10.10.11.240: icmp_seq=8 ttl=64 time=88.8 ms
64 bytes from 10.10.11.240: icmp_seq=9 ttl=64 time=893 ms
64 bytes from 10.10.11.240: icmp_seq=10 ttl=64 time=692 ms
64 bytes from 10.10.11.240: icmp_seq=11 ttl=64 time=493 ms
64 bytes from 10.10.11.240: icmp_seq=12 ttl=64 time=291 ms
64 bytes from 10.10.11.240: icmp_seq=13 ttl=64 time=88.5 ms
64 bytes from 10.10.11.240: icmp_seq=14 ttl=64 time=894 ms
64 bytes from 10.10.11.240: icmp_seq=15 ttl=64 time=691 ms
64 bytes from 10.10.11.240: icmp_seq=16 ttl=64 time=490 ms
64 bytes from 10.10.11.240: icmp_seq=17 ttl=64 time=290 ms
64 bytes from 10.10.11.240: icmp_seq=18 ttl=64 time=87.3 ms
^C
--- 10.10.11.240 ping statistics ---
19 packets transmitted, 18 received, 5.26316% packet loss, time 3690ms
rtt min/avg/max/mdev = 87.260/457.881/894.212/278.671 ms, pipe 5

All pings get answered, but only once per second. It seems like incoming packets are stored in a buffer, and whatever deals with the packets is only called once per second. Does anyone else have this issue too?

Edit: This issue does not exist with WiFi. I get pretty consistent 10ms latency with that.

Turns out i had the INT pin soldered incorrectly. Kind of a fun failure mode, actually.

[tbnobody]

This PR is no more required as the SpiManager was now merged.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.