Page 1 of 1
Plans to further abstract ethernet TCPIP adapters?
Posted: Tue Oct 23, 2018 11:47 am
by Resch2061
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?
Re: Plans to further abstract ethernet TCPIP adapters?
Posted: Wed Oct 24, 2018 2:10 am
by ESP_Sprite
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.
Re: Plans to further abstract ethernet TCPIP adapters?
Posted: Thu Oct 25, 2018 2:07 pm
by Resch2061
That's interesting, good to know. I'm sure it could be of use to other people as well.
Re: Plans to further abstract ethernet TCPIP adapters?
Posted: Thu Oct 25, 2018 2:11 pm
by ESP_igrr
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.
Re: Plans to further abstract ethernet TCPIP adapters?
Posted: Fri Oct 26, 2018 9:01 am
by Resch2061
Will it allow for entirely different transportation methods as well, i.e. using SPI to communicate with the Ethernet chip?
Re: Plans to further abstract ethernet TCPIP adapters?
Posted: Tue Oct 30, 2018 2:49 am
by ESP_morris
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.
Re: Plans to further abstract ethernet TCPIP adapters?
Posted: Tue Oct 30, 2018 1:54 pm
by Resch2061
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.