Plans to further abstract ethernet TCPIP adapters?

Resch2061
Posts: 40
Joined: Mon May 01, 2017 1:56 pm

Plans to further abstract ethernet TCPIP adapters?

Postby Resch2061 » Tue Oct 23, 2018 11:47 am

Hey guys. This topic is mostly meant towards the good developers over at Espressif.

I'm looking at the TCPIP layer at the moment, and I'm interested at implementing a different Ethernet chip, of which I'm currently writing some drivers. I chose one that doesn't have a tcpip stack implemented, as it already exists within the ESP32. I'm at the stage where I can reliably read and transmit data from and to the chip, and I've been doing some digging to see how the ESP32 handles the TCPIP stack layer and the built-in ethernet chip... only to find it's kinda sorta hardwired into the tcpip adapter files. This isn't really an issue per-say, I mean, I can easily patch the whole thing to route the I/O wherever necessary... but it's kind of a dirty solution, heh.

In other words, I wish to continue to use the already existing TCPIP adapter pipeline. It's just the transportation method should change from the already existing mac and PHY drivers to the one I have written.

Do you happen to have plans to further abstract this layer, so users can change the chip on their system without having to apply patches that end up breaking compatibility with the IDF?

ESP_Sprite
Posts: 8921
Joined: Thu Nov 26, 2015 4:08 am

Re: Plans to further abstract ethernet TCPIP adapters?

Postby ESP_Sprite » Wed Oct 24, 2018 2:10 am

As far as I know, there's nothing on the roadmap. If you have some fixes that make it easier to add additional adapters, we4'd be open to seeing a pull request to integrate that in esp-idf, however.

Resch2061
Posts: 40
Joined: Mon May 01, 2017 1:56 pm

Re: Plans to further abstract ethernet TCPIP adapters?

Postby Resch2061 » Thu Oct 25, 2018 2:07 pm

That's interesting, good to know. I'm sure it could be of use to other people as well.

ESP_igrr
Posts: 2067
Joined: Tue Dec 01, 2015 8:37 am

Re: Plans to further abstract ethernet TCPIP adapters?

Postby ESP_igrr » Thu Oct 25, 2018 2:11 pm

Also note that we do have a new Ethernet driver on the way, but since it has to break some existing APIs, it will not be merged until we start development of ESP-IDF v4. Currently v3.2 is coming to a pre-release stage, and after that there's going to be a v3.3.

This new driver should allow for adding support for MACs other than the one in the ESP32.

Resch2061
Posts: 40
Joined: Mon May 01, 2017 1:56 pm

Re: Plans to further abstract ethernet TCPIP adapters?

Postby Resch2061 » Fri Oct 26, 2018 9:01 am

Will it allow for entirely different transportation methods as well, i.e. using SPI to communicate with the Ethernet chip?

ESP_morris
Posts: 290
Joined: Wed Sep 05, 2018 6:23 am

Re: Plans to further abstract ethernet TCPIP adapters?

Postby ESP_morris » Tue Oct 30, 2018 2:49 am

Thanks for your good suggestion.
Actually the EMAC driver should be low coupling with the RTOS and TCP/IP stack.
For now, we're refactoring it, and add an abstract interface for EMAC and PHY, so that it will easier to add support for other PHY and EMAC.
The interface may be like this:

Code: Select all

struct eth_mac_if_s {
    /* attributes */
    eth_phy_if_t *phy;                    /*!< Ethernet PHY which is connected to MAC */
    uint8_t address[ETH_MAC_ADDR_LENGTH]; /*!< Ethernet MAC Address */
    eth_link_status_t link;               /*!< Ethernet Link Status */
    eth_speed_t speed;                    /*!< Ethernet Speed */
    eth_duplex_mode_t duplex;             /*!< Ethernet MAC Duplex Mode */
    //ToDo
    /* methods */
    esp_err_t (*init)(eth_mac_if_t *mac);                                                /*!< Initialize */
    esp_err_t (*del)(eth_mac_if_t *mac);                                                 /*!< Delete */
    esp_err_t (*deinit)(eth_mac_if_t *mac);                                              /*!< Deinitialize */
    esp_err_t (*start)(eth_mac_if_t *mac);                                               /*!< Start */
    esp_err_t (*stop)(eth_mac_if_t *mac);                                                /*!< Stop */
    esp_err_t (*check_link)(eth_mac_if_t *mac);                                          /*!< Check Link and Response */
    esp_err_t (*smi_read)(eth_mac_if_t *mac, uint16_t phy_reg, uint16_t *reg_value);     /*!< SMI Read */
    esp_err_t (*smi_write)(eth_mac_if_t *mac, uint16_t phy_reg, uint16_t reg_value);     /*!< SMI Write */
    esp_err_t (*trans_frame)(eth_mac_if_t *mac, uint8_t *buf, uint32_t frame_length);    /*!< Transmit one Frame */
    esp_err_t (*recept_frame)(eth_mac_if_t *mac, uint8_t **buf, uint32_t *frame_length); /*!< Recept one Frame */
    //ToDo
};
I hope this is what you want. :D

Resch2061
Posts: 40
Joined: Mon May 01, 2017 1:56 pm

Re: Plans to further abstract ethernet TCPIP adapters?

Postby Resch2061 » Tue Oct 30, 2018 1:54 pm

Looks good to me. I assume these function pointers would feed the LWIP TCPIP stack with data as well, correct? Perhaps you could make the default event handlers available in a header file.

That's another thing I've had a little bit of annoyance with - the default event handlers. I'm aware you can directly call esp_eth_init_internal, which circumvents the default event handlers, but here's the thing - some things about the default handlers I wanna keep, and some others I don't. Like the way it starts DHCP clients or static IP addresses. Making the default event handler functions available in a header file would definitely help here.

Another suggestion I have is more flexibility with LWIP's ethif struct - like in the file components/lwip/port/netif/ethernetif.c. This file is directly referenced in the tcpip_adapter_lwip.c file, heh.

Who is online

Users browsing this forum: No registered users and 105 guests