Support to W5100 in eth (IDFGH-948)

[ghost]

Eth does not support the W5100 chip communicating through SPI. Are you planning to add?

[twelve12pm]

This would be a good way to add multi-homed capability with potentially many additional Ethernet ports.

[xiongyumail]

Hi @alexmanoelaccessrun Why not use LAN8720 PHY? It's cheaper and faster, using ESP32 EMAC.

[ghost]

Hi @xiongyumail

My project is designed to save space and GPIOs. It's already a finished product, I'm just thinking of upgrading the firmware to an ESP-IDF API development standard.

[me-no-dev]

W5100 (or any similar chip) is not and can not be compatible with LwIP, because it integrates it's own TCP/IP stack. ENC28J60 can be made to work (probably) because it does not have such TCP/IP stack and is less or more direct interface to Ethernet. If you just want to use W5100 in your code and do no care for it to be fully integrated inside IDF, you can pull esp32-arduino as component, grab one of the W5100 compatible libraries for it and use just that (no need to use the full Arduino suite)

[ghost]

Hello @me-no-dev

Although there is no intention of adding support for the W5100, a standardization rule for development using these types of chips is lacking in the documentation. This would make it easier to identify libraries that are not compatible.

[me-no-dev]

@alexmanoelaccessrun when you say that the documentation is lacking something like that, same could be said for many other things. Obviously we can not add every possible case in the documentation and I do not think that it's needed. You as a developer should understand the components that you are planning to use and be able to predict what you will need to do to get them going.

Again, W5100 is not an Ethernet controller in the wide sense :) it's MCU+Ethernet geared towards chips and applications that can not handle the whole TCP/IP stack on their own (because of lack of memory, clock speed or else). Honestly I will never consider them for ESP32. LwIP coupled with other chips are much more powerful.

[ghost]

The http_client library for example I do not know if it can be used in conjunction with my implementation of W5100 or if I will be forced to redo the entire abstraction of that library into a new implementation that is compatible.

[ghost]

@me-no-dev I understand that the W5100 is not compatible with the LwIP and that is why it is not possible to add support for it at this level. I also understand that it is not possible to add all the exceptions to the documentation, but I was trying to say that it is lacking to make clear the dependency relationship between the basic ESP-IDF components.

For example, the relationship between Http Client and LwIP: In the documentation there is not enough information about the communication between them or dependency relationship.

This information would greatly assist in integrating these components without the need to analyze the entire component code.

[me-no-dev]

LwIP provides the TCP/IP stack for ESP32. All network services are based on that. It implements the NETCONN interface on top of the RAW LwIP API. NETCONN is also the base for the POSIX socket interface, which in turn is used in almost all network services/apps on the ESP32. So LwIP(raw->netconn->socket) -> Http Client

[telliottosceola]

@me-no-dev I know this issue is closed but I'm looking at using the ENC28J60. And it seems relevant here. The reason I am interested in the ENC28J60 is because it mounts over SPI and the LAN8720/tlk110 do not. I cannot commit all the GPIOs required for the LAN8720/TLK110 as they are already being used for our application. I require TLS which I believe by default will work with ETHClass since it mounts to lwip which WiFiClientSecure uses. Could you confirm that WiFI ClientSecure will work with ETHClass? And if so could you point me in the right direction to port support for the ENC28J60 to the ETHClass? I have not worked at this level before and it appears all of the lower level files are compiled in some way as they have a .a extension. I just need a nudge in the right direction as to where to start. @copercini please also chime in if you have any insights.

[me-no-dev]

@telliottosceola wrong repository? Getting proper support for ENC28J60 in LwIP should be possible and there might already be some effort if you search online. AMF ENC28J60 is more suited for implementation than W5100 because it is just an interface and passes all data through. It's really slow though... slower than WiFi :)

[telliottosceola]

Thanks @me-no-dev for the reply. I understand what you're saying about the W5100 and I have given up on that. I think ENC28J60 is the best suited IC for this application. I have found a little bit to start with here. However I'll be completely honest this is a little lower level than I generally go. PHY is new to me as well, I've always just used WiFi. For my application speed is not a problem as pretty much all communications are via MQTTS and are infrequent. So how would I go about starting this port? I have ported libraries before but at higher levels(generally cpp). It appears I'll need to implement similar functionality to phy_lan8720 but I only see h files in the toolchain. Where are the C files? Looks like maybe everything is compiled into .a files. Could you give me a gentle nudge in the right direction? Again thank you @me-no-dev I really appreciate all of your work around here. I use the Async Web Server like crazy and it works great!

[me-no-dev]

this source? :) https://github.com/espressif/esp-idf/tree/master/components/ethernet

[negativekelvin]

@suda-morris since there is spi-ethernet support now can we reopen this request for w5100/w5500 to be supported? Especially since esp32-s2 has no emac.

https://github.com/johnnytolengo/w5500lwip

[suda-morris]

Hi @negativekelvin Thanks for your interest. Yes, the reason we add SPI-Ethernet module is esp32-s2 won't have emac internally. But there're two kinds of SPI-Ethernet module, one is MAC+PHY+SPI, and another is MAC+PHY+TCP/IP+SPI. For now we only support the former one. Since the latter one have conflict with the software lwip stack, so we might add another abstract socket layer to including they two if we plan to support W5500.

[negativekelvin]

@suda-morris It doesn't really have conflict with lwip if you use it in "macraw" mode, as shown in the linked poc repo, raw frames can be passed to lwip. dm9051 is not as cheap and widely available as w5100s or w5500.

[suda-morris]

Thanks @negativekelvin OK, I will take time to do some research on it. But as far as I know, W5500 is much different from DM9051 or ENC28J60 regarding to the register description. For example, W5500 doesn't provide the standard PHY registers which makes it hard to add W5500 to current Ethernet driver model.

Also, the "MACRAW" mode will waste the most important feature of W5500. :|

[negativekelvin]

@suda-morris Yes I know, sad to make it work as a dumb chip and have a bunch of stub functions that do nothing. But it is cheap and popular so people will use it.

[projectgus]

dm9051 is not as cheap and widely available as w5100s or w5500.

I agree the Wiznet chips are widely available, especially in hobbyist/Maker products because of the Arduino board support.

However, regarding cheap, this may depend on source but I'm not sure it's the case (at least for qty > 1):

• https://lcsc.com/product-detail/Ethernet-ICs_DAVICOM_DM9051NP_DAVICOM-DM9051NP_C113756.html
• https://lcsc.com/product-detail/Ethernet-ICs_WIZNET_W5100_W5100_C18866.html
• https://lcsc.com/product-detail/Others_WIZNET_W5100S_WIZNET-W5100S_C194673.html
• https://lcsc.com/product-detail/Ethernet-ICs_WIZNET_W5500_W5500_C32843.html

The tradeoff for ESP-IDF, as @suda-morris says, is supporting something which has a quite different device interface from a typical Ethernet PHY.

The work @suda-morris has been doing on the Ethernet driver model means that it's much easier now to add a PHY driver for a new type of chip. Starting from the PoC code for "MACRAW" mode it should be possible for someone to write a standalone driver component, external to ESP-IDF, that integrates pretty well with ESP-IDF and otherwise uses the standard TCP/IP and network driver stack.

But it's not clear to us that the cost/benefit is worth it for direct support in ESP-IDF. As opposed to using the Wiznet chips on smaller micros where the integrated TCP/IP stack is clearly a killer feature.

[negativekelvin]

@projectgus hmm, yes price is not so bad for dm9051, almost the same as w5100s for 1k @ digikey https://www.digikey.com/product-detail/en/wiznet/W5100S-L/1278-1030-ND/8789606 but since w5100 is more capable, dm9051 should be cheaper

I do think a wiznet driver would be a popular feature, but certainly up to you whether you want to support it. Maybe it could be an example in esp-iot-solution.

Will there be usb-ethernet support for esp32-s2?

[suda-morris]

That's a good point @negativekelvin we might have such a driver (e.g. AX88772) in the future to make esp32s2 have another choice running Ethernet.

[drdelgado]

Thank you @negativekelvin what would be a good drop in chip with documentation supporting for ESP32 and ethernet integration? I've currently toyed with the Olimex board however I do not like the breakout pins they provide are quite limited.

[negativekelvin]

dm9051 is the only supported phy that uses less pins because it is an SPI interface

[KaeLL]

it should be possible for someone to write a standalone driver component, external to ESP-IDF, that integrates pretty well with ESP-IDF and otherwise uses the standard TCP/IP and network driver stack.

Let me ask it explicitly: is it POSSIBLE to write a driver for W5100 that integrates with ESP-IDF seamlessly? If so, any tips?

[suda-morris]

@KaeLL My answer is, yes, it's possible to.

You should enable "MACRAW" mode to by pass its internal TCP/IP engine, and implement the interface for MAC and PHY side, using the SPI driver. FYI, you can read the enc28j60 example first.

[KaeLL]

Also, the "MACRAW" mode will waste the most important feature of W5500.

What did you mean by this @suda-morris ?

[suda-morris]

enable MACRAW so that you can't use the HW TCP/IP Engine which is the killer feature of W5500

[KaeLL]

Thank you.

[KaeLL]

@suda-morris another question: will a software interrupt based implementation incur issues other than with performance? Sorry to bother, last question, I promise :P

[suda-morris]

Sorry @KaeLL I didn't try in this way before, I'm afraid I can't give you a 100% right answer. But at an intuitive level, it's possible to, at the cost of a huge performance lose.

[KaeLL]

Since I think this is the reference thread for this subject, I just wanted to say that I ported the W5100 to work with esp-idf, and I'm posting here because...

• future reference: maybe other people will find themselves in the same situation (unlikely someone would pair both these chips, I know, yet here I am).
• feedback: literally anything, except code-style related. It'd be most appreciated as I'm still learning my way around the network stack, and there's still improvements to be made.

Here's the repo of an example consisting of the http client and mqtt examples: https://github.com/KaeLL/ESP32-W5100

[tbrusa]

W5100 (or any similar chip) is not and can not be compatible with LwIP, because it integrates it's own TCP/IP stack. ENC28J60 can be made to work (probably) because it does not have such TCP/IP stack and is less or more direct interface to Ethernet.

That's not true. You can use the W5100 in MACRAW mode and still make use of the LwIP stack.

[ghost]

@tbrusa the @KaeLL implementation on https://github.com/KaeLL/ESP32-W5100 use W5100 in MACRAW to ESP-IDF and works with LwIP stack.

[KaeLL]

Feedback and PRs are welcome, btw.