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

Add LAN8720 phy support #383

Closed
wants to merge 5 commits into
base: master
from

Conversation

Projects
None yet
@RobinCutshaw
Contributor

RobinCutshaw commented Feb 26, 2017

No description provided.

@CLAassistant

This comment has been minimized.

CLAassistant commented Feb 26, 2017

CLA assistant check
All committers have signed the CLA.

@negativekelvin

This comment has been minimized.

Contributor

negativekelvin commented Feb 26, 2017

Could you fix debug logging to use ESP_LOGD?

@RobinCutshaw

This comment has been minimized.

Contributor

RobinCutshaw commented Feb 26, 2017

The original code uses ESP_LOGI so I followed it by example. Should the original code remain ESP_LOGI and the new code use ESP_LOGD?

@projectgus

Thanks for contributing this, we really appreciate it.

I've requested a couple of small changes/clarifications. The bigger questions around naming I'm happy for us to deal with later, unless you're particularly inspired to do some refactoring along those lines. :)

Regarding ESP_LOGD vs ESP_LOGI, as this is a fairly low-level technical example I think we can afford to keep the default ("info" level) output fairly technical like this. Some time down the road, if/when the PHY support code gets refactored into a library, we may change some of this.

#if (CONFIG_PHY_LAN8720)
if (debug)
dump_lan8720_registers();
#endif

This comment has been minimized.

@projectgus

projectgus Feb 27, 2017

Member

For code like the above it's preferable to define a single function name, something like static void dump_phy_registers and name both PHY-specific versions the same. The #ifdef guards will determine which one is compiled in.

This comment has been minimized.

@RobinCutshaw

RobinCutshaw Feb 27, 2017

Contributor

My original plan was to pull all of the phy code out of ethernet_main.c and put it in separate source files. That is a little more work but I'm happy to do that now if preferred.

This comment has been minimized.

@RobinCutshaw

RobinCutshaw Feb 27, 2017

Contributor

I've refactored by moving the phy code out of ethernet_main.c so there is no phy device specific code there. Now would be the time to change the logging level before I check in. Preferences?

eth_config_t config;
config.phy_addr = PHY31;
// config.phy_addr = PHY31;
config.phy_addr = PHY1; // tlk eval board

This comment has been minimized.

@projectgus

projectgus Feb 27, 2017

Member

Is this an intentional change to the TLK1110 config?

This comment has been minimized.

@RobinCutshaw

RobinCutshaw Feb 27, 2017

Contributor

The upstream repository uses PHY31 which would be specific to the original author and their hardware. I changed it to the default for the evaluation boards for both the TLK110 and LAN8720. I left the original commented out so the original author could easily change it. Ideally, what I should do is place the PHY ID in the menuconfig file.

config.phy_get_duplex_mode = phy_lan8720_get_duplex_mode;
config.phy_get_partner_pause_enable = phy_lan8720_get_partner_pause_enable;
config.phy_power_enable = phy_lan8720_power_enable;
#endif

This comment has been minimized.

@projectgus

projectgus Feb 27, 2017

Member

I'm not sure about the naming here either.

It may make more sense, long term, to split these PHY-specific functions into individual source files and have extern eth_config_t lan8270_eth_config and extern eth_config_t tlk110_eth_config or something like this.

You don't need to change that in this PR unless you want to, it's something we can rework in a follow-up (eventually some of this will probably be moved to library code, as well.)

This comment has been minimized.

@RobinCutshaw

RobinCutshaw Feb 27, 2017

Contributor

Yes, I had planned to rework this if the code I submitted was of interest.

@@ -0,0 +1,17 @@
menu "Example Configuration"
config PHY_TLK110

This comment has been minimized.

@projectgus

projectgus Feb 27, 2017

Member

For these kind of options, it's better to use a "choice". Something like this: https://github.com/espressif/esp-idf/blob/master/components/freertos/Kconfig#L14 (note the "choice" keyword starts the series of choices, until the "endchoice" line.)

This comment has been minimized.

@RobinCutshaw

RobinCutshaw Feb 27, 2017

Contributor

Ok. I looked at all of the Kconfig file examples under the examples tree and didn't see an example of that. I'll make the change.

static const char *TAG = "eth_demo";
extern void phy_device_check_phy_init(void);

This comment has been minimized.

@projectgus

projectgus Feb 27, 2017

Member

Feel free to disagree with me here, but I think rather than declare all these functions as extern, it may be better to make them static in the individual source files and then declare inside each PHY-specific file

const eth_config_t tlk110_default_ethernet_phy_config = {
    .phy_check_init = phy_tlk110_check_phy_init,
    .phy_check_link = phy_tlk110_check_phy_link_status,
    .phy_get_speed_mode = phy_tlk110_get_speed_mode,
    .phy_get_duplex_mode = phy_tlk110_get_duplex_mode,
    .flow_ctrl_enable = true;
    .phy_get_partner_pause_enable = phy_tlk110_get_partner_pause_enable,
etc}

And then in this code:

extern const eth_config_t tlk110_default_ethernet_phy_config;

Which then be either passed to the esp_eth_init() directly (if the signature is changed to const), or copied to another structure which is then passed in directly.

This also has the advantage that you don't need to selectively compile the source files, we can compile both but only one will be linked into the final binary depending on which extern-ed config structure is used.

(Sorry if this seems different to what I was suggesting before, I realised I gave two different recommendations as I read my way through the code.)

This comment has been minimized.

@RobinCutshaw

RobinCutshaw Feb 27, 2017

Contributor

There are a couple of functions in the eth_config structure that come from ethernet_main instead of the phy support code so a phy function like:

eth_config_t *eth_config = phy_device_get_config(eth_gpio_config_rmii, tcpip_adapter_eth_input);

or the structure would not be const and ethernet_main would just set those functions. Given that there may be more than one ethernet project in the future, the phy code should probably move out from the project and into a component support library (in the future). That would make me lean towards the eth_config function approach.

This comment has been minimized.

@RobinCutshaw

RobinCutshaw Feb 27, 2017

Contributor

Here is the latest suggestion. lan8720_phy.c has:

    void phy_update_config(eth_config_t *config);

and ethernet_main.c has:

    eth_config_t config;
    config.gpio_config = eth_gpio_config_rmii;
    config.tcpip_input = tcpip_adapter_eth_input;
    config.phy_power_enable = phy_device_power_enable;
    phy_update_config(&config);
    ret = esp_eth_init(&config);

This comment has been minimized.

@projectgus

projectgus Feb 27, 2017

Member

This is really a minor variation on your suggestion, but what about:

eth_config_t config = tlk110_default_ethernet_phy_config;
config.gpio_config = eth_gpio_config_rmii;
config.tcpip_input = tcpip_adapter_eth_input;
config.phy_power_enable = phy_device_power_enable;
ret = esp_eth_init(&config);

This means that you don't need to selectively compile each PHY source file, they can all be compiled but only one will be picked up at link time (because of the individual name tlk110_default_ethernet_phy_config). This will probably help once the code is in a comonent support library (which I agree should be the goal), as many non-example users probably won't need to support multiple PHYs and therefore won't find the overhead of sdkconfig phy selection useful.

Eventually, we can probably also push some of these generic functions (like tcpip_adapter_eth_input) into the "default" config for each PHY as well.

This comment has been minimized.

@RobinCutshaw

RobinCutshaw Feb 28, 2017

Contributor

I liked (in my version) that ethernet_main did not need to know anything about the underlying phy. Does it make a difference (other than compile time) whether you do selective compiling or selective linking? Your version would need ifdefs around the version of the struct to pull. If you feel strongly about it, I'll happily shut up and go with your version... :)

This comment has been minimized.

@projectgus

projectgus Feb 28, 2017

Member

There are a couple of considerations:

  • We try to use code-as-configuration where possible instead of sdkconfig. This often leads to more understandable code (if each PHY symbol has a different name, it's obvious what the intention of the phy configuration selection is from reading the calling code in ethernet_main. Whereas using the same name to configure PHYs means a reader has to also look at the component.mk file in order to see the full picture of what's happening, and how the three parts - sdkconfig, build configuration, ethernet_main - join together.)
  • The second reason is that for Arduino and some other environments (like Micropython/NodeMCU) the maintainers build a single set of libraries and then link to those. For these environments to support multiple PHYs, they have to be able to access them all simultaneously without rebuilding or reconfiguring IDF.
    Thanks for being patient with all my requests. :)

EDIT: Changed readable to understandable above, as you're totally correct that the version without #ifdefs reads clearer. It's just harder to understand exactly what it does, without looking at some additional pieces.

#include "lan8720_phy.h"
extern char *demo_tag;

This comment has been minimized.

@projectgus

projectgus Feb 27, 2017

Member

better to do something like static const char *TAG = "lan8720"; here, similar for the other PHY.

This comment has been minimized.

@RobinCutshaw

RobinCutshaw Feb 27, 2017

Contributor

Ok, that works.

@projectgus

This comment has been minimized.

Member

projectgus commented Feb 27, 2017

Thanks for the quick update, loosk good. I left a couple more comments. Feel free to let me know if you think it's better to go in a different direction, I'm not very familiar with the ethernet support yet (still waiting on a development board.)

@ESP32DE

This comment has been minimized.

Contributor

ESP32DE commented Feb 27, 2017

Some time down the road, if/when the PHY support code gets refactored into a library, we may change some of this.

hello angus,
mhm, i'm sorry if i anticipate something,
between the lines i read that the code/PHY support code in the near future only appears as lib?
when the new design appears to the eth board, will there be open code or lib?

best wishes
rudi ;-)

@projectgus

This comment has been minimized.

Member

projectgus commented Feb 27, 2017

between the lines i read that the code/PHY support code in the near future only appears as lib?
when the new design appears to the eth board, will there be open code or lib?

Sorry, I used the wrong language. I mean a component (specifically a component which provides generic library-style support for PHYs, rather than keeping it in the example code.) We intend to keep the ethernet support fully open source.

@projectgus

Thanks for all your work on this, I like this structure a lot better overall.

@@ -32,92 +32,47 @@
#include "tcpip_adapter.h"
#include "nvs_flash.h"
#include "driver/gpio.h"
#include "tlk110_phy.h"
extern void phy_update_config(eth_config_t *config);

This comment has been minimized.

@projectgus

projectgus Mar 1, 2017

Member

I think this declaration is a leftover here

}
}
// uncomment for console debug messages
#define DEMO_DEBUG 1

This comment has been minimized.

@projectgus

projectgus Mar 1, 2017

Member

This pattern is not really "the IDF way". Use ESP_LOGD or ESP_LOGI to set the debug levels based on how important you think the output is.

Users can override the logging level (either per-file or globally) in various ways as described here:
http://esp-idf.readthedocs.io/en/latest/api/system/log.html

As I said before, I don't feel strongly about whether this example output should be ESP_LOGD or ESP_LOGI. Whichever you think is more useful is fine.

#define PHY_ID PHY0
// uncomment for console debug messages
//#define PHY_DEBUG 1

This comment has been minimized.

@projectgus

projectgus Mar 1, 2017

Member

Same comment about debugging conventions applies here.

// select phy device
//extern eth_config_t lan8720_default_ethernet_phy_config;
//#define PHY_CONFIG lan8720_default_ethernet_phy_config
extern eth_config_t tlk110_default_ethernet_phy_config;

This comment has been minimized.

@projectgus

projectgus Mar 1, 2017

Member

For the example, it's nicer to conditionally compile this lines based on an sdkconfig choice (similar to the first version of this PR). Sorry if I accidentally gave you the impression that I wanted that removed.

Also, the "extern eth_config_t ..." declarations can be moved to the respective PHY headers.

phy_enable_flow_ctrl();
}
eth_config_t lan8720_default_ethernet_phy_config = {

This comment has been minimized.

@projectgus

projectgus Mar 1, 2017

Member

This can be "const eth_config_t", in which case it lives in flash to save RAM.

phy_enable_flow_ctrl();
}
eth_config_t tlk110_default_ethernet_phy_config = {

This comment has been minimized.

@projectgus

projectgus Mar 1, 2017

Member

This can be "const eth_config_t", in which case it lives in flash to save RAM.

@projectgus

This comment has been minimized.

Member

projectgus commented Mar 2, 2017

Thanks Robin, looks very good. I've squashed these commits and put them into our internal review/merge queue. I'll let you know how things progress.

We're still gearing up for the V2.0 release (which is already feature complete), so a final merge may be a little delayed. Thanks for being patient with us!

@projectgus

This comment has been minimized.

Member

projectgus commented Mar 6, 2017

Hi Robin,

Quick update on this: no problems with the code surfaced in internal review. The only thing was some discussions around support-ability once merged to IDF.

We're going to mark LAN8720 as contributed/unsupported when we merge, but we're also going to order some LAN8720 modules so we can test these changes in-house before merging and (hopefully) verify any other major ethernet changes that may impact LAN8270 (although we won't be guaranteeing support.)

Thanks for being patient with us.

Angus

@RobinCutshaw

This comment has been minimized.

Contributor

RobinCutshaw commented Mar 6, 2017

Thanks Angus. I've submitted a couple of new pull requests that move the phy support under the components tree and added ethernet support to the http_request example. These are obviously dependent on the original patch. Please take a look at the http_request pull request and let me know if that is the direction you would like to go. I hope to add ethernet support to all of the examples if that is ok.

@RobinCutshaw

This comment has been minimized.

Contributor

RobinCutshaw commented Apr 8, 2017

It has been a while since this was approved. I had time to design and test a "ESP32 Etherbase" ethernet proto board with the LAN8720A. It is working well. Hopefully we can get these changes applied so we don't get so far away from the master.

Robin

img_0644

img_0641

@projectgus

This comment has been minimized.

Member

projectgus commented Apr 10, 2017

Hi @RobinCutshaw ,

Very nice board! Is the design open source anywhere?

Sorry I didn't update you earlier. During our internal review process, we decided that one of our engineers should make a test setup with this PHY before we merge it. The engineer failed to get a LAN8270 breakout board working correctly, and then had higher priority work take him away from this. The task was handed back to me a couple of weeks ago. I have a LAN8720 board here but I haven't had time to wire it up yet. Hopefully soon.

Thanks for being patient while we work through this.

Angus

@ESP32DE

This comment has been minimized.

Contributor

ESP32DE commented Apr 10, 2017

The engineer failed to get a LAN8270 breakout board working correctly,

perhabs this helps:
http://www.waveshare.com/w/upload/0/08/LAN8720-ETH-Board-Schematic.pdf

I have a LAN8720 board here but I haven't had time to wire it up yet

incredible
it's a five minute test!

img_6008_s

everything is described neatly

img_6139_s

many manufacturer build ESP32 ETH PHY Boards

lan_can_monster_s

olimex makes now ETH PHY + CAN too
https://olimex.wordpress.com/2017/04/06/esp32-evb-now-get-much-better/
..
incredible

the most loved ones which makes the esp32 so interesting like LAN(ETH PHY) + CAN
are totally neglected. these two work come completely by/from third party

and the theme pSRAM ..
i speak and ask not more in and about this - now near 5 month waiting for details
speechless ( for not taking time )

@RobinCutshaw
nice board!
thank you for your effort on ETH PHY with LAN8720 and your work on ESP-IDF
as third party component, that's the best way for it now and for future other things ( openWiFi ...)

@igrr

This comment has been minimized.

Member

igrr commented Apr 10, 2017

@ESP32DE

everything is described neatly

If you can point us to the description of correct wiring, it would probably speed up things significantly!

@ESP32DE

This comment has been minimized.

Contributor

ESP32DE commented Apr 10, 2017

@igrr

WROVER-KIT Waveshare LAN8720 Breakout

must_IO22 ->TX1
must_IO21 ->TX_EN
must_IO25 ->RX0
must_IO00 ->nINT/RETCLK
user_IO18 ->MDIO
must_GND ->GND
must_VCC ->VCC 3.3V
must_IO19 -> TX0
must_IO26 -> RX1
must_IO27 -> CRS
user_IO23 -> MDC

user_IO23
user_IO18

#define PIN_SMI_MDC   23
#define PIN_SMI_MDIO  18

example as jpeg from pdf
example as pdf

@ESP32DE

This comment has been minimized.

Contributor

ESP32DE commented Apr 10, 2017

eth_phy_connectings

hope this helps for

it would probably speed up things significantly!

best wishes
rudi ;-)

@ESP32DE

This comment has been minimized.

Contributor

ESP32DE commented Apr 10, 2017

btw:

the must ETH PHY RMII pins are from esp32 pin list
side 4

pin_list

RMII side 5

pin_list_5

the details from the ESP32 technical reference manual
side 45, 46

edit:
and last but not least:
there is a ethernet tlk110 demo code with the must pins for ETH PHY RMII in the esp-idf examples folder

void eth_gpio_config_rmii(void)
{
    //txd0 to gpio19 ,can not change
    PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO19_U, FUNC_GPIO19_EMAC_TXD0);
    //tx_en to gpio21 ,can not change
    PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO21_U, FUNC_GPIO21_EMAC_TX_EN);
    //txd1 to gpio22 , can not change
    PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO22_U, FUNC_GPIO22_EMAC_TXD1);
    //rxd0 to gpio25 , can not change
    gpio_set_direction(25, GPIO_MODE_INPUT);
    //rxd1 to gpio26 ,can not change
    gpio_set_direction(26, GPIO_MODE_INPUT);
    //rmii clk  ,can not change
    gpio_set_direction(0, GPIO_MODE_INPUT);

    //mdc to gpio23 
    gpio_matrix_out(PIN_SMI_MDC, EMAC_MDC_O_IDX, 0, 0);
    //mdio to gpio18
    gpio_matrix_out(PIN_SMI_MDIO, EMAC_MDO_O_IDX, 0, 0);
    gpio_matrix_in(PIN_SMI_MDIO, EMAC_MDI_I_IDX, 0);
}

same is then in the LAN8720

;-)

be sure you set phy addr right.
the tlk110 demo code from espressif used PHY31 as address

config.phy_addr = PHY31;

the EVB tlk110 used PHY0

the Waveshare LAN8720 breakboard Adapter used PHY1

config.phy_addr = PHY1;

@RobinCutshaw

This comment has been minimized.

Contributor

RobinCutshaw commented Apr 10, 2017

Here are the pin definitions in the IDF code:

`void eth_gpio_config_rmii(void)
{
//crs_dv to gpio27 ,can not change (default so not needed but physical signal must be connected)
//PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO27_U, FUNC_GPIO27_EMAC_RX_DV);

//txd0 to gpio19 ,can not change
PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO19_U, FUNC_GPIO19_EMAC_TXD0);
//tx_en to gpio21 ,can not change
PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO21_U, FUNC_GPIO21_EMAC_TX_EN);
//txd1 to gpio22 , can not change
PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO22_U, FUNC_GPIO22_EMAC_TXD1);
//rxd0 to gpio25 , can not change
gpio_set_direction(25, GPIO_MODE_INPUT);
//rxd1 to gpio26 ,can not change
gpio_set_direction(26, GPIO_MODE_INPUT);
//rmii clk  ,can not change
gpio_set_direction(0, GPIO_MODE_INPUT);

//mdc to gpio23
gpio_matrix_out(PIN_SMI_MDC, EMAC_MDC_O_IDX, 0, 0);
//mdio to gpio18
gpio_matrix_out(PIN_SMI_MDIO, EMAC_MDO_O_IDX, 0, 0);
gpio_matrix_in(PIN_SMI_MDIO, EMAC_MDI_I_IDX, 0);

}
`
I used the Microchip/SMSC EVB8720 eval board in it's default configuration. The default PHY_ID is 0 so you will need to change the phy_addr from PHY31 in the IDF master branch. The PIN_PHY_POWER isn't used with the eval board so I either hit reset several times to get to the right mode or disconnect the clock pin while booting. The key for receive is to connect GPIO27 to the CRS_DV pin on the PHY. If you are not using the EVB8720 (which has pull ups on mode pins), you will need to add the mode bits in software when you configure the phy.

`
#define AUTO_NEG_ADVERTISEMENT_REG (0x4)
#define ASM_DIR BIT(11)
#define PAUSE BIT(10)
#define MODE_100_FULL_DUPLEX BIT(8)
#define MODE_100_TX_ABLE BIT(7)
#define MODE_10_FULL_DUPLEX BIT(6)
#define MODE_10_ABLE BIT(5)
#define MODE_ALL 0x01e0

void phy_enable_flow_ctrl(void)
{
uint32_t data = 0;
data = esp_eth_smi_read(AUTO_NEG_ADVERTISEMENT_REG);
esp_eth_smi_write(AUTO_NEG_ADVERTISEMENT_REG,data|ASM_DIR|MODE_ALL|PAUSE);
// esp_eth_smi_write(AUTO_NEG_ADVERTISEMENT_REG,data|ASM_DIR|PAUSE);
}
`

Robin

@sauttefk

This comment has been minimized.

Contributor

sauttefk commented Apr 18, 2017

KSZ8091RNACA also seems to be an interesting ETH-PHY. It features on-chip 50Ω termination resistors. Pricing is 1.36 EUR (for one piece)

@sauttefk

This comment has been minimized.

Contributor

sauttefk commented Apr 18, 2017

@ESP32DE maybe you want to change your modified schematics for the waveshare LAN8720:
R12 is not optional
R11 is not populated on the waveshare LAN8720 board

Reason: LED2 is connected to AVdd so the PHY is bootstrapped to nINTSEL=1.
nINTSEL=1 -> nINT/REFCLKO is configured as interrupt output (no clock signal on this pin)

BTW: LED1 is connected wrongly. The LED1 should be connected to GND to ensure REGOFF=0 see datasheet page 32 section 3.8.1.1

@ESP32DE

This comment has been minimized.

Contributor

ESP32DE commented Apr 18, 2017

@sauttefk
you mean like this?

eth_phy_lan8720_mod_clk_var1

Because I have something to contradict you.

be sure you double check your LAN8720 module
there are difference moduls on market ( cheap and expensives )
and some are QC passed and some are copies with small changes

same is with R11 and R12
some are R12 optional and used the RefCLK as CLK
some are R11 optional ( NC ) and used CLK direct

my generates clk on gpio16 works like a charme on one without mounted OSZ
and is working full time very nice.

on other there is missing parts on modul.....and other routing..
and i have not install the "missing" resistor like robin example.
so i think we speak here from more as 3 difference moduls.

i am happy - i have working boards here now and i am happy with my code now.
i ordered now the same working modules again with greater batch with and without mounted OSZ.

Times a handful for the photo and log

img_6289_s

created now and use now own third party support for LAN8720, this merging theme get on nerves
sry.

perhabs this DP83848 is alternate too if someone has this older ETH PHY

eth_phy_dp83848_1

It would be very interesting if we get to see the tlk110 board once thought in final;
Because the example code in esp-idf is originally the TLK110.

How does it look, is there already the reference design to the TLK110 code ready now?
there was a big announcement for the tlk110 board as a reference design in the past.
but was not done public...

KSZ8091RNACA
this theme we had spoke in the past
..

25_50

we have a base in the repo ( tlk110 ) and i am sure ,
everyone will use his favorite eth phy in his way, which is most familiar to him.

and I think that this has also been thought of by espressif in the sense of this example.

not to include any available hw on the market in the esp-idf;

but it would have been wise to check available modules for availability on the market and then provide a corresponding demo code;

an affordable and available tlk110 breakout module I have not seen so far unfortunately.

It was therefore only a question of the time the LAN8720 to support, even if it is about third party now happens;

Many the demo code should only be adapted to LAN8720 and optionally a TLK110 example perhabs.

LAN8720 is simply more popular and available.

@ESP32DE

This comment has been minimized.

Contributor

ESP32DE commented Apr 18, 2017

@sauttefk

btw:
the 4.7 kOhm solution
this is already here in my post in the past :)

the original comes from MC

and looks like this:

eth_phy_lan8720_4 7_solution_with_clk_enable

and ETH_PHY_ENABLE pin goes then to EN the clk ...

this snip shows too, we can use 25 MHz for the LAN8720 and LAN8720 generate the 50MHz on RefCLK
so the mean of R12 as "optional" was well thinked

;-)

best wishes
rudi ;-)

@ESP32DE

This comment has been minimized.

Contributor

ESP32DE commented Apr 18, 2017

@sauttefk
comment to the edit post

BTW: LED1 is connected wrongly. The LED1 should be connected to GND to ensure REGOFF=0 see datasheet page 32 section 3.8.1.1

thats one of more problems with the modules on market,
the WAVESHARE module shows no resistor on the last place
lan8720-eth-board_l_1_5

but point in the wiki still to mounted things in the shematic

lan8720-eth-board_l_1_5_s

..
so double check the used LAN8720 Modul
and check the routing....

best wishes
rudi ;-)

@sauttefk

This comment has been minimized.

Contributor

sauttefk commented Apr 18, 2017

@projectgus: could you please merge this pull request. I think it has been proven by several people here, that the code is working as intended.

@sauttefk

This comment has been minimized.

Contributor

sauttefk commented Apr 18, 2017

@ESP32DE

this snip shows too, we can use 25 MHz for the LAN8720 and LAN8720 generate the 50MHz on RefCLK
so the mean of R12 as "optional" was well thought

yes sure, but this means either

  • populate R12

or

  • populate R11 and also change the bootstrap on LED2 nINTSEL=0 to get the 50MHz REFCLKO on pin 14 nINT/REFCLKO of LAN8720

to get a 50MHz signal on the R_RXCLK pin of the pinheader of the waveshare module.

led12-bootstrapping

projectgus added a commit that referenced this pull request Apr 20, 2017

@projectgus

This comment has been minimized.

Member

projectgus commented Apr 20, 2017

Thanks everyone for the information and for your patience with this. As I'm sure you can all appreciate, we have a lot of open tasks and sometimes things we'd love to see done are pushed behind more urgent items.

I finally had time yesterday and I wired up my LAN8720, everything worked fine. I've also rebased this branch on the current master, and added a couple of things:

  • Refactored the PHY support into the ethernet component - which makes it easier to reuse between projects. This is very similar to Robin's work in #398, only goes a little further with removing duplicate code and aiming to provide ways that common PHY driver code can be reused/shared.
  • Expanded the README for the ethernet example, based on the details provided by @ESP32DE , @RobinCutshaw & @sauttefk in this thread. Should make it quicker for new folks to get up and running.

The branch is back in the internal review queue, so it may not be merged to master for a few days yet. I've pushed it temporarily/unofficially here: https://github.com/espressif/esp-idf/compare/temp/ethernet_lan8720 in case anyone would like to take a look or test it out beforehand.

Expect a proper merge to master very shortly, though. Thanks again for bearing with us.

PS @sauttefk Very nice blog post and trick using the spare pin on the Waveshare module for oscillator Enable!

@RobinCutshaw

This comment has been minimized.

Contributor

RobinCutshaw commented Apr 20, 2017

The ethernet_lan8720 branch works well on my ESP32 Etherbase board (which has the LAN8720). I like the other refactoring you did as well.

igrr pushed a commit that referenced this pull request Apr 25, 2017

igrr pushed a commit that referenced this pull request Apr 25, 2017

Merge branch 'feature/ethernet_lan8720' into 'master'
ethernet: Add LAN8720 phy support, move PHY to components

Encompasses PR #383 #383

Also includes changes to move PHY support functions into ethernet component, similar to #398 https://github.com/espressif/esp-idf/pull/398/files.





See merge request !540
@projectgus

This comment has been minimized.

Member

projectgus commented Apr 25, 2017

Cherry-picked in 5d6e6f7. Thanks for all the input folks, and thanks for sending the original PR @RobinCutshaw .

@projectgus projectgus closed this Apr 25, 2017

@santanapablo1975

This comment has been minimized.

santanapablo1975 commented Apr 26, 2017

Hi All,

I see here that everybody is working with ESP32 and Ethernet.

I have tried also with success the ESP32 and the LAN Board from wave share (DP83848) with small changes from the ESP32 example.

Now I have a general question... waht about if I want to connect direct my PC to the ESP32 via the Ethernet interface, would that be possible? or at least has any sense?

Thanks in any case for your contributions to the ESP32 community!

Regards/Saludos/Gruesse

Juan

@ahmedjouirou

This comment has been minimized.

ahmedjouirou commented May 1, 2017

@santanapablo1975 , can you please share the DP83848 port ? i mean if you have made like a "phy_dp83848.h/c" sources ?

Thanks !

@santanapablo1975

This comment has been minimized.

santanapablo1975 commented May 2, 2017

@Nakul93

This comment has been minimized.

Nakul93 commented Jul 19, 2017

@ESP32DE Where should we connect PIN_PHY_POWER on lan8720 board?

@Nakul93

This comment has been minimized.

Nakul93 commented Jul 20, 2017

Hey @projectgus
I am unable to get in the write mode each time I have to press reset multiple times before I get in the right mode.
This what I get on serial monitor:
rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun 8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun 8 2016 00:22:57

//After pressing reset for the 3rd time I got in to the right mode
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0008,len:8
load:0x3fff0010,len:160
load:0x40078000,len:10632
load:0x40080000,len:252
entry 0x40080034
ETH started
ETH MAC: 24:0A:C4:01:82:EF
ETH connected
ETH IPv4: 192.168.0.107

TIA

@RobinCutshaw

This comment has been minimized.

Contributor

RobinCutshaw commented Jul 20, 2017

The PIN_PHY_POWER is normally used to turn on/off the power to the ethernet PHY or to control a mosfet or clock enable pin (that you add in your design) that blocks the 50MHz clock from GPIO0. If the clock is running and connected to GPIO0 when you boot, you have a 50/50 chance of going into bootloader mode or normal boot. If you are using an external PHY board to test, you will need to manually remove power or disconnect the clock from GPIO0 while booting.

@Nakul93

This comment has been minimized.

Nakul93 commented Jul 20, 2017

So if I make those changes as suggested by @sauttefk connecting the PIN_PHY_POWER pin to the clock enable of lan8720 would that work without having to continuously reset to get in to the right mode.

@RobinCutshaw

This comment has been minimized.

Contributor

RobinCutshaw commented Jul 20, 2017

@igrr igrr removed the merge pending label Nov 14, 2017

@Arthedian

This comment has been minimized.

Arthedian commented May 11, 2018

Hello,
is it possible to change the connection of CLK pin to GPIO0? I want to use ethernet, but my dev board, which i bought dont have GPIO0 on its header.

@sauttefk

This comment has been minimized.

Contributor

sauttefk commented May 11, 2018

@projectgus

This comment has been minimized.

Member

projectgus commented May 14, 2018

@Arthedian You may be able to reconfigure to generate the clock from the ESP32 and output on GPIO 16, as noted at the link @sauttefk sent.

You can set the clock mode in the eth_config_t structure passed when you configure the clock, see here:
http://esp-idf.readthedocs.io/en/latest/api-reference/ethernet/esp_eth.html#_CPPv2N12eth_config_t10clock_modeE

@Arthedian

This comment has been minimized.

Arthedian commented May 21, 2018

Thanks for your support. Fortunately now I got ESP32 with PIN0, so its no problem. But when I connected it to the LAN8720 (I double check the connection), it gives me this error. Do you know, where the problem could be?

E (1304) emac: Timed out waiting for PHY register 0x2 to have value 0x0007 (mask 0xffff). Current value 0xffff
E (2304) emac: Timed out waiting for PHY register 0x3 to have value 0xc0f0 (mask 0xfff0). Current value 0xffff

EDIT: Fixed, when config.phy_addr changed to config.phy_addr = PHY1;

@Arthedian

This comment has been minimized.

Arthedian commented Jul 16, 2018

Hello, I have another question. Can i have ethernet connected to esp and load the code at once? I already have transistor between pin0 and ethernet.

@tantu1293

This comment has been minimized.

tantu1293 commented Jul 23, 2018

Hello, I have another problem.
I choose REF_CLK Out Mode with crytal 25MHz for comunication between my custom PCB Lan8720 and ESP32-wroom- 32D. I configured LED2 pin and LED1 pin following datasheet to get CLK.
After that, I use ETHERNET example code to test. But I can't obtain IP Adrress . This is log which i have
capture
So, i read datasheet and "rev D schematic checklist" of Lan8720 again. And i find out some things.
lan8720
What should i do ?
May anybody help me ? Please.
Thanks.

@theElementZero

This comment has been minimized.

theElementZero commented Oct 14, 2018

Hi All,

I see here that everybody is working with ESP32 and Ethernet.

I have tried also with success the ESP32 and the LAN Board from wave share (DP83848) with small changes from the ESP32 example.

Now I have a general question... waht about if I want to connect direct my PC to the ESP32 via the Ethernet interface, would that be possible? or at least has any sense?

Thanks in any case for your contributions to the ESP32 community!

Regards/Saludos/Gruesse

Juan

Hi Juan, i am trying to interface DP83848 with ESP32, i am facing some issue, i would like to know what all possible changed needed in phy_xxxx.c file for this PHY.

would like to know your inputs.

Regards
Sushant

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