New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding W5500 support to ethernet component #4424
Conversation
I tried to give this a go, but couldn't make it very far. Because this is the first SPI-based ethernet chip being added, I think there's more that needs to change in esphome. All of the configurable options for the ethernet component (MDC/MDIO pins, etc) don't apply and there's no way to set the config for other more critical options (interrupt pin for MACRAW mode, CS pin for SPI). Here's what I see: Config (the values don't make sense, but are required fields):
Output:
|
O wow, how could I not have spotted that. I'll look into this more closely in the coming days. In the meantime: if anyone has suggestion for how to get the config schema to support this, be welcome to share snippets of code or to make your own PR. I'm just starting to understand this all. |
Haha yeah, if it was this easy I would have added all of the SPI drivers when upgrading the ethernet component late last year. In terms of making the config work, we can change to using a |
Ok, I thought I had the typed_schema figured out (adding options for (s)clk, miso, mosi and cs pins) until I noticed that the SPI component exists, which should probably be used here. I haven't tried yet, but I can probably use the spi_device_schema. But then what? I found https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/network/esp_eth.html#spi-ethernet-module , but I don't really understand how that would work with the SPI component yet. Any hints are welcome! |
I did have success using the custom component in https://github.com/spali/esphome-components/blob/master/components/ethernet_spi/ethernet_spi.cpp with the W5500, which I think might contain most of the "necessary" bits to making something like this work. There are quite a lot of substantial changes so maybe this is better as an independent component? |
I didn't put more effort in https://github.com/spali/esphome-components/tree/master/components/ethernet_spi because I think it should be integrated into the base |
@spali Thank you for your message. It seems that the config schema is not the hardest part: as Jesse suggested a ethernet:
type: W5500
clk_pin: GPIO18
mosi_pin: GPIO23
miso_pin: GPIO19
cs_pin: GPIO26 The thing is: that would completely bypass the SPI component. I think that (but I'm by no means an expert on any of this would mean that you would have to have a separate SPI bus for the ethernet chip. I.e. it would be impossible to share the SPI pins in use for the ethernet chip with other SPI devices. Possibly it would be nicer if we could do something like this: spi:
clk_pin: GPIO18
mosi_pin: GPIO23
miso_pin: GPIO19
ethernet:
type: W5500
cs_pin: GPIO26 I personally doubt this is feasible, because I don't see the connection or overlap between the SPI component and the code for SPI based ethernet chips. But I'm just a PHP programmer working on some hobby electronics projects, so it's very plausible that I'm not seeing something that is very much there. Second question is: would going with the first, simpler, route, be a reason to not support SPI based ethernet connectivity at all? I hope @jesserockz or any of the other maintainers have the time to share their vision on that. |
From the user perspective, I think the SPI component (second example of you) would make sense to define the common SPI stuff, as it can have multiple SPI bus and it seems to align also with other SPI components configuration like displays etc. in esphome. |
Ok got some time to do a small test. Together the display does not work. If I comment the I fear this is a fundamental problem of how esphome uses the SPI bus on esp-idf. @jesserockz correct me, but I think esphome does not use the esp-idf provided methods to initialize the SPI bus. And maybe this just won't work together. If that assumption is true... either esphome must use the esp-idf methods for SPI stuff (may break a lot of SPI related stuff) or we must somehow reimplement the convenient ethernet driver stuff from esp-idf to work on top of how esphome works (if that is possible). @jesserockz Do we have any existing SPI devices that partially or fully make use of the esp-idf provided methods? edit: @JeroenVanOort Basically kind of a prove what you already mentioned 😉 |
got a working draft: Currently SPI is handled in the ethernet component. Declaring the SPI component let it still work, but in my tests with an SPI display only one component works at a time. Most critical part to do now would be to somehow streamline SPI part to work with the existing When or better if we get this working... we can clean the code to maybe create an ethernet base class and only share the code that is not implementation (driver) specific. |
@spali thanks for the great work. I tested your code on a custom made W5500 / ESP32C3, see picture below. After adjusting the SPI_HOST -> 2 it works great. ESP32C3 has 1 SPI Host less;-) The board is made for processing P1 smart meter data (DSMR). The DSMR component unfortunately only works on the Arduino framework. Is there a way to use your code for the Arduino framework as well? |
@mhendriks was wondering about your config. I'm trying to get it setup on C3 as well and I'm still getting compiling issues. Where is the SPI_HOST thing you mentioned? |
replace the SPI3_HOST in ethernet_component.cpp (2x) See the config below
|
@mhendriks @clomads |
Thank you both for your work @spali @mhendriks
|
try newer esphome or try at least newer espidf framework. possible that 4.4.3 or better 4.4.4 is required.
|
@spali thanks for the fixes/changes. I didn't tell yesterday that I had removed the part below. This because of the error: 'esp_eth_mac_new_esp32' was not declared in this scope. The adjustments work great on the C3 (after removing the part below). Tested on:
@clomads you are using exactly the same io assignment for the spi interface. You are shure this is correct? |
@spali @mhendriks I'm on latest main release 2023.2.4 via HA add-on and I checked another device with IDF by adding debug component and it's compiling with 4.4.2 by default so forcing 4.4 made the compiler freak out even more. My main error as shown in my log file is: |
I got it to compile by removing those lines that @mhendriks mentioned. No network connection yet bc I'm gonna have to tighten up my wiring or put it on a perfboard. |
found and fixed the problem for the not declared methods. Not sure why the define |
Thank you all for the work on this! I was able to get it to work using a plain ESP32. Like @mhendriks I'm also trying to use the DSMR component so I looked at getting this to work with the Arduino framework. What seems to be holding it back are the two calls to I think these are the TODO's for now:
Nice to have's:
@spali Where do we go from here? I could work on all but resolving the other TODO's in the code and make a PR to your branch, from which you make a PR to upstream. This PR can be closed. Other option would be for me to copy to code to my branch, update this PR with my changes and then get it merged. But that kinda feels like stealing the credits for the effort you made. One last thing regarding the chips that have one less SPI bus than the plain ESP32: does this mean that SPI ethernet would could not go together with the SPI component? I understand there will need to be 2 separate SPI buses, but it seems like these chips wouldn't be able to do that. If so, this could use a check in the code and must absolutely be mentioned in the documentation that is to be added. |
Don't worry about stealing 😉 I'm fine if you copy paste. Would prefer that you are independent of me for finishing this PR. Regarding SPI... yes that would be a limitation for now, as I couldn't get any other SPI device to work as soon as I used the esp-idf SPI initialization stuff (did not test if devices are on separate SPI bus). But I don't know if the PR would get merged with that limitation. I was hoping someone with more in deep knowledge of the current SPI implementation could help us here to get it work. |
@JeroenVanOort Would you be able and willing to share your Arduino version of the code? I would also like to experiment with it ;-) |
f01b0e5
to
29a54ee
Compare
29a54ee
to
9f4ae4c
Compare
With M5Stack POE CAM https://docs.m5stack.com/en/unit/poe_cam and following config: esphome:
name: domofon
esp32:
board: m5stack-core2
framework:
type: esp-idf
external_components:
- source:
type: git
url: https://github.com/JeroenVanOort/esphome/
ref: eth-w5500
components:
- ethernet
ethernet:
type: W5500
mosi_pin: GPIO13
miso_pin: GPIO38
clk_pin: GPIO23
cs_pin: GPIO4
clock_speed: 10Mhz
ota:
logger:
level: debug it fails with:
With default platform it works (despite nasty line:)
|
Great work.
|
Well done to all for their work on this! Can this be extended to the rpi2040 too please? I have some W5500-EVB-Pico units to test on if it helps |
I have successfully tested this with the M5Stack AtomPoE using: external_components:
- source:
type: git
url: https://github.com/JeroenVanOort/esphome/
ref: eth-w5500
components: [ ethernet,network,api,esp32 ]
ethernet:
type: W5500
clk_pin: GPIO22
mosi_pin: GPIO33
miso_pin: GPIO23
cs_pin: GPIO19
clock_speed: 16Mhz |
for [pixelwave]
Please could you put your configuration with the correction here? I can't get it to work, thank you |
Board LILYGO T-ETH-Lite [https://www.lilygo.cc/products/t-eth-lite] esphome: logger: api: external_components:
ethernet: I don't know how to insert the code so that it is correct, I'm sorry, if someone explains it to me I would appreciate it. |
I have successfully tested with the M5Stack Module-LAN-13.2 too:
Bootlog
|
Tested on the m5stack Atom Lite (ESP32-PICO-D4 based). Only the I've tried both Removing network components such as OTA, web_server, time, etc doesn't seem to make a difference. The connection being lost is confirmed with an ongoing ICMP ping. Config
Bootlog
This component also conflicts with any use of BLE and crashes:
|
Oh wow, I didn't expect this.. But this PR gives me the right ideas to implement this for the Arduino-Pico RP2040 core. A W5500-ECB-Pico board specifically, on-board W5500 chip and ethernet jack. I'm a bit suprised that noone ever wanted to run ESPHome on such a platform? But I'll take the opportunity. Edit: Have done so in https://github.com/maxgerhardt/w5500-evb-pico-esphome |
72985d0
to
71be204
Compare
71be204
to
4815ae9
Compare
@jesserockz Could you provide some practical help? I don't understand what you're pointing to. With this, I hope this PR can be merged soon. |
@JeroenVanOort your latest changes seem to have broken it for me on the M5 Atom PoE on ESPHome 2024.2.0
Switching back to WiFi it works fine =( |
Have you tried lowering the clock speed? For example: ethernet:
clock_speed: 10Mhz |
It worked fine previously at 16MHz and has the same error at 10MHz. |
Can confirm that the following code works for me on ESP32-S3 using the Arduino Framework:
Been running for 4 days straight without any drops, very stable so far but will run for a while longer. For some reason as mentioned above, it doesn't seem to work if the framework is switched to ESP-IDF which surprised me, I expected the other way around if anything. |
Ill see if I can figure it out. I was not a big part in the recent SPI refactor so I am learning how that works too. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## dev #4424 +/- ##
==========================================
+ Coverage 53.70% 53.80% +0.09%
==========================================
Files 50 50
Lines 9408 9445 +37
Branches 1654 1661 +7
==========================================
+ Hits 5053 5082 +29
Misses 4056 4056
- Partials 299 307 +8 ☔ View full report in Codecov by Sentry. |
What does this implement/fix?
This adds support for the W5500 chip to the
ethernet
component.Types of changes
Related issue or feature (if applicable): fixes esphome/feature-requests#1235
Pull request in esphome-docs with documentation (if applicable): esphome/esphome-docs#2843
Test Environment
Example entry for
config.yaml
:Checklist:
tests/
folder).If user exposed functionality or configuration variables are added/changed: