[eppp]: Support for transport via Ethernet (phy or emac) #622
Conversation
david-cermak
force-pushed
the
feat/eppp_emac2emac
branch
from
150f1b3 to
001855e
Compare
|
|
||
| - Internal EMAC with real PHY chip | ||
| * TCP - 5Mbits/s | ||
| * UDP - 8Mbits/s |
There was a problem hiding this comment.
I'm quite surprised with such poor performance. Do you have idea what could be the bottle neck and why it isn't at least as good as SDIO?
There was a problem hiding this comment.
would probably get similar performance as SDIO, after some optimizations; tested just briefly with all defaults.
I'm planning on looking into it at some point.
david-cermak
force-pushed
the
feat/eppp_emac2emac
branch
from
001855e to
da05de2
Compare
|
@kostaond Thanks taking a look at the emac2emac option. I must say that I concur with your assessment and think that this option is probably not a viable transport option for My suggestion is that we drop the emac2emac option in this PR, but allow the Ethernet init/start functionality to be extended (with callbacks or |
Agree, if you need to move forward, drop the emac2emac. It's currently too much polluted with the GPIO0 workaround. Presence or non presence of the workaround must be super clear to users because the most probable use case is to use ESP32 with WiFi connected to some other chip without WiFi. |
david-cermak
force-pushed
the
feat/eppp_emac2emac
branch
from
da05de2 to
35f9579
Compare
Removed the emac2emac from the component and added it as an extra example with the specific configuration, so the GPIO0 workaround is in the app code only. (Moreover It demonstrates using any custom Ethernet driver) |
| sscanf(CONFIG_EPPP_LINK_ETHERNET_THEIR_ADDRESS, "%2" PRIu8 ":%2" PRIu8 ":%2" PRIi8 ":%2" PRIu8 ":%2" PRIu8 ":%2" PRIu8, | ||
| &s_their_mac[0], &s_their_mac[1], &s_their_mac[2], &s_their_mac[3], &s_their_mac[4], &s_their_mac[5]); | ||
| esp_eth_ioctl(s_eth_handles[0], ETH_CMD_S_MAC_ADDR, s_our_mac); | ||
| ESP_RETURN_ON_ERROR(esp_event_handler_register(ETH_EVENT, ESP_EVENT_ANY_ID, event_handler, NULL), TAG, "Failed to register Ethernet handlers"); |
There was a problem hiding this comment.
Should we open space for a custom event handler?
There was a problem hiding this comment.
I wouldn't create a custom handler/even-loop for eppp as I don't think it's necessary at this point. we can always add that later.
What would be the purpose of these custom events?
| TaskHandle_t task_handle = xTaskGetHandle(pcTaskGetName(NULL)); | ||
| gpio_isr_handler_add(CONFIG_EXAMPLE_RMII_CLK_READY_GPIO, gpio_isr_handler, task_handle); | ||
| ESP_LOGW(TAG, "waiting for RMII CLK sink device interrupt"); | ||
| ESP_LOGW(TAG, "if RMII CLK sink device is already running, reset it by `EN` button"); |
There was a problem hiding this comment.
Should we make it part of the source device to automatically reset the device if the user enables it?
There was a problem hiding this comment.
we would need some other signalling method to perform the reset of the other device, right? (I think @bogdankolendovskyy suggested a similar handshaking mechanism with GPIOs like that, but it was rejected by @kostaond for being "too complicated", correct?)
david-cermak
force-pushed
the
feat/eppp_emac2emac
branch
from
35f9579 to
e03a0cd
Compare
david-cermak
force-pushed
the
feat/eppp_emac2emac
branch
from
e03a0cd to
de4af56
Compare
|
@kostaond @euripedesrocha Thanks for your review, I've reworked this PR, so that it uses "just Ethernet" with customizable initialization. Then (in a separate commit) I've added the EMAC-2-EMAC example with all those workarounds and magic delays. |
Using a dummy phy, by means of EMAC to EMAC connection