Wired Ethernet support?

[dreamy1]

not an issue :-)

Hello,

is it planned to add wired ethernet support for this great work?

Actually, there are some modified variants of your software with support for e.g. LAN8720. The only difference for the software part is that the SPI bus for the lcd and sd card has to be moved to the second hardware SPI bus (called HSPI) because the RMII pins are needed for the LAN chip. In consequence, some pins have to be switched but this should not be a problem because of the GPIO definition in the NVS text file.

An ethernet connection is for most users with an automation systems the best choice. The RMII interface of the ESP32 supports wired ethernet out-of-the-box.

Here is an example schematic showing the new pin definitions - VS1053, Ethernet via RMII and LCD are possible at the same time:

[dreamy1]

@tsctrl : maybe you need a second resistor as pull-up for the GPIO0 of the ESP32: https://sautter.com/blog/ethernet-on-esp32-using-lan8720/

With this modification the LAN8720 should work without problems.

[tsctrl]

thanks @dreamy1, i follow that blog during my test. have pull up hook up on gpio0 and pull down on gpio17. Same as what @Edzelf does in the lib to use GPIO0OUT as esp generate the oscillator. maybe @Edzelf also have the same issue by using the W32 ETH01 module.

look like esp does not detect the freq during boot. so i am too lazy to hook osciloscope and debug further and just use esp oscillation mode as what had work.

esp32 is very strong chip. 240mhz it is quite fast. i guess spi w5500 could work well. i am still waiting my w5500 module to test.

@Edzelf can consider to integrate with w5500 module too? would be great as gpio is very limited. we lost 6 pins by using LAN8720 and only 2 by using W5500. we could reprioritize que on w5500 spi bus to balance the speed and allow smooth playback.

[Edzelf]

Further testing: I tested the WT32-ETH01 module with the VS1053 (SPI) without problems. Pins used:

pin_vs_cs = 2        # GPIO VS1053 CS
pin_vs_dcs = 12      # GPIO VS1053 DCS
pin_vs_dreq = 4      # GPIO VS1053 DREQ
pin_spi_sck = 5      # GPIO SPI SCK
pin_spi_miso = 33    # GPIO SPI MISO
pin_spi_mosi = 17    # GPIO SPI MOSI

Next step: SPI display.

[Edzelf]

Further testing: I tested he WT32-ETH01 module with VS1053 and SPI display (BLUETFT) without problems. Station at 320 kbps. Pins used:

pin_vs_cs = 2        # GPIO VS1053 CS
pin_vs_dcs = 12      # GPIO VS1053 DCS
pin_vs_dreq = 4      # GPIO VS1053 DREQ
#
pin_spi_sck = 5      # GPIO SPI SCK
pin_spi_miso = 33    # GPIO SPI MISO
pin_spi_mosi = 17    # GPIO SPI MOSI
#
pin_tft_cs = 35      # GPIO BLUETFT CS
pin_tft_dc = 14      # GPIO BLUETFT A0

[dreamy1]

Thanks Ed for the update!

It seems that the WT32-ETH01 has other GPIO definitions than the "standard" ESP32? For example, the GPIO35 is input only, so that would not work as chip_select for the TFT (here a GPIO output is required). EDIT: just had a look at the datasheet - GPIO35 is input. So i am wondering that the TFT works...

One thing what is not clear for me: do you use real hardware spi of the second spi bus (HSPI) or does your code still use the first spi bus (VSPI) which is routed over the GPIOMUX to the non-standard-pins? That will cost extra performance - but maybe it is not a problem.

[tsctrl]

is there any gpio left for ir and rotary switch? i hope we dont have to integrate an i2c io extender. my experience integrating those is a nightmare. it is slow and not suitable for rotary encoder, use lots of codes to deal with i2c bus and need it own process to run. @Edzelf please consider to add w5500 instead.

[tsctrl]

hi @dreamy1 i not sure if gpio gmux involve. but the codes use existing vspi bus with a non standard pin definition. i not sure if using existing bus with hspi pin definition will use secondary bus automatically or will use gmux. this need to be address or asked to expressif if you will. else current implementation need to follow multiple bus implementation as example i had mention previously.

i have use the codes that was done by @Edzelf without any changes on the bus implementation. just change the pin definition to hspi pins and it work without any lags on the spi bus. run with lan vs decoder.

[Edzelf]

@dreamy1: You are right about pin35, it is input only. But as you can see in the picture, the display functions normally. You may connect CS of the display to ground and it will still work. You may also use pin 15, it is still unused @tsctrl: there are pins for the rotary encoder (al inputs): 35, 36, 39 (ypu ave to supply PULL-UPs I think). I cammot test the W5500, as I do not have one, but I quess it will work as well.

[dreamy1]

Thanks again for the update - it seems that the chip select is not neccessary for the display to work :-)

For the spi bus, seems that the GPIOMUX is used and the VSPI is still active with routinng to the new spi pins. For an explicite use of direct hardware HSPI a new class has to be defined (that is what i have learned). But when all is working properly, there is absolutely no need to change anything. I have searched about that and found out that the use of the GPIOMUX is absolutely no problem with spi speeds below 10 MHz, so this is safe here.

[tsctrl]

hi @Edzelf

i have use gpio as below for my setup but the rotary encoder only response to volume up and down rotation. no 2 or single press mute was detected.

pin_enc_clk = 34 # GPIO Pin number for rotary encoder CLK pin_enc_dt = 39 # GPIO Pin number for rotary encoder DT pin_enc_sw = 36 # GPIO Pin number for rotary encoder SW

i have added 3 pull up 10k to all the pin without any efect.

[Edzelf]

Pin 36 is reserved for battery level, see the progpin table. Better use pin 35.

[tsctrl]

Hi @Edzelf ,

could sent me your address to tsc7rl@gmail.com? would like to sent you the ethernet modules to your address. will try if possible to sent this from china.

i have added sd, ir and rotary and now there is not enough gpio for possible buttons, backlight, i2c modules, i2s and usb. wrover module has pin 16 and 17 reserved for internal psram

thanks!

[tsctrl]

hi @Edzelf , any choppy playback on 320kbps stream? any valid channel with 320kbps to try?

look like ethernet are slower than wifi. i am only getting around 1400 bytes length per client read, do you have this issue once before migrating to AsyncTCP?

[Edzelf]

With the search function in yhe webinterface you can find 320 kbps streams. AsyncTCP has a 5 kB buffer if I remember well.