8000 ports/esp32: Add support for SPI-based ethernet chips by damz · Pull Request #10420 · micropython/micropython · GitHub
[go: up one dir, main page]

Skip to content

ports/esp32: Add support for SPI-based ethernet chips #10420

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

Merged
merged 2 commits into from
Jan 18, 2023

Conversation

damz
Copy link
Contributor
@damz damz commented Jan 6, 2023

What?

Add support for various SPI-based ethernet chips (W5500, KSZ8851SNL, DM9051) to the ESP32 port.

The impetus for this was to support the POE Featherwing, which is based on the Wiznet W5500 chip.

How?

Leverage the existing support in ESP-IDF for these chips, and the existing support for network.LAN in the ESP32 port.

In particular, this doesn't leverage the wiznet5k support that is used on the rp2 and stm32 ports.

A note on testing

I tested this on the POE Featherwing (with the SJIRQ solder jumper bridged) and a ESP32-S3 feather.

While I do not have access to hardware using the other chips, the set up method for them comes from the ethernet/basic example from ESP-IDF 4.4, so I am relatively confident that it is correct.

A note about the interrupt pin

The W5500 implementation within ESP-IDF relies on hardware interrupt, and requires the interrupt pin from the W5500 to be wired to a GPIO. This is not the case by default on the Adafruit Ethernet FeatherWing, which makes it not directly compatible with this implementation.

8000

@damz damz force-pushed the pr/ethernet-support branch 2 times, most recently from 169992b to a2c2865 Compare January 6, 2023 05:54
@damz damz marked this pull request as ready for review January 6, 2023 05:59
@beyonlo
Copy link
beyonlo commented Jan 8, 2023

@damz Hello.

I don't know if this can help you, but maybe this has a very good relation with this PR. The Wiznet ethernet SPI chips already works on RP2040 and STM, so, maybe to port that to ESP32 is a good idea to be a common base for many ports!

@beyonlo
Copy link
beyonlo commented Jan 8, 2023

@damz

In particular, this doesn't leverage the wiznet5k support that is used on the rp2 and stm32 ports.

I'm sorry, you already made it clear that this PR implementation does not use that implementation that I linked before.

Thank you.

@stephanelsmith
8000 Copy link
Contributor

Love this PR. Would be a great addition, especially with ESP-IDF 4.4 underlying support.

@damz damz force-pushed the pr/ethernet-support branch 2 times, most recently from ef4f210 to 385ae05 Compare January 13, 2023 05:04
@damz
Copy link
Contributor Author
damz commented Jan 13, 2023

@dpgeorge Thanks for the review. I updated the PR.

@damz damz force-pushed the pr/ethernet-support branch 2 times, most recently from 37d00d9 to 9dd8d06 Compare January 13, 2023 05:52
@damz
Copy link
Contributor Author
damz commented Jan 17, 2023

@dpgeorge I think all your comments so far have been addressed.

damz added 2 commits January 18, 2023 11:16
Add support for various SPI-based ethernet chips (W5500, KSZ8851SNL,
DM9051) to the ESP32 port.  This leverages the existing support in ESP-IDF
for these chips -- which configures these chips in "MAC raw" mode -- and
the existing support for network.LAN in the ESP32 port.  In particular,
this doesn't leverage the wiznet5k support that is used on the rp2 and
stm32 ports (because that's for native use of lwIP).

Tested on the POE Featherwing (with the SJIRQ solder jumper bridged) and a
ESP32-S3 feather.

A note about the interrupt pin: The W5500 implementation within ESP-IDF
relies on hardware interrupt, and requires the interrupt pin from the W5500
to be wired to a GPIO.  This is not the case by default on the Adafruit
Ethernet FeatherWing, which makes it not directly compatible with this
implementation.
`esp_eth_ioctl(ETH_CMD_S_MAC_ADDR)` sets the MAC address of the hardware
device, but we also need to notify the upper layers of the change so that
e.g. DHCP work properly.
@dpgeorge dpgeorge force-pushed the pr/ethernet-support branch from 9dd8d06 to c7301b8 Compare January 18, 2023 00:20
@dpgeorge
Copy link
Member

I rebased this on latest master.

@dpgeorge dpgeorge merged commit c7301b8 into micropython:master Jan 18, 2023
@dpgeorge
Copy link
Member

Thanks @damz for this, it's a good enhancement!

@damz damz deleted the pr/ethernet-support branch January 18, 2023 02:17
@beyonlo
Copy link
beyonlo commented Feb 28, 2023

Hello

I'm very happy that we are closer to have SPI-based ethernet chips really supported on the ESP32 family! That feature is something amazing for many projects!

I have some questions:

Add support for various SPI-based ethernet chips (W5500, KSZ8851SNL, DM9051) to the ESP32 port.

  1. About the Wiznet chip, will works just with the W5500, or also others 5K family chips will be supported, like as the W5100S?
  2. Will that ethernet chips works as mac raw mode? I mean, the limits of sockets for example, SSL, etc, will works by ESP-IDF, not from chip limits?
  3. Everythink that works on IP using the WiFi, will works via Ethernet? I mean, SSL, and so on. I understand that as that support are in ESP-IDF, should be a transparent way and everything works as on the WiFi.
  4. Will be possible to use at the same time WiFi and Ethernet? I mean, I will have two interfaces (IPs) running together.

Thank you in advance!

@licsber
Copy link
licsber commented Jun 13, 2023

Hello

I test esp32-20230426-v1.20.0.bin with ESP32-WROOM-32E chip, but when i import network, there is no PHY_W5500 enum. Just get DP83848 IP101 LAN8710 LAN8720 RTL8201.

Is there any examples for using SPI-based Ethernet chips ? Does i need compile firmware myself?

Also test nightly firmware esp32-20230610-unstable-v1.20.0-189-gfd277704c.bin, no help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants
0