RPi Pico: 100BASE-T with cheap ethernet PHY module | Hacker News Reader

RPi Pico: 100BASE-T with cheap ethernet PHY module

github.com

84 pointsmborges16 comments

The page mentioned using the RP2040 to generate the clock signal. Does the PHY not have this built in? Is there an advantage to doing it this way? (Or is this the only way it is possible?)

I have no idea how this works, but that stuck me as interesting.

The PHY does have a clock built in. They're clocking their writes themselves so that the clock is synchronized with the microcontroller state. For example, here's the code to send a bit to the PHY:

https://github.com/maximeborges/pico-rmii-ethernet/blob/main...

(It sets the clock pin to 0, sleeps for a microsecond, puts the data bit on the data pin and sets the clock to 1, then sleeps for a microsecond.)

That's pulsing the clock of the mdio (so config i2c) not the pio of the main data over rmii.

Main tx data loop that depends on the 50mhz clock generated by the rp2040 is here. https://github.com/maximeborges/pico-rmii-ethernet/blob/main...

That makes more sense. I avoided doing the math to determine that a 2 microsecond cycle time is not 50MHz (it's 500kHz), and in doing so, linked to the wrong thing :)

Without having read the data sheet… It is probably to keep the devices synchronized. Reading data from an unsynchronized input takes, um, waving hands here, 2 to 10 times the effort and resources.

If you are old enough to remember serial ports on computers, this is the “16 times oversampling!” bullet point. They oversampled and then state machined their way back to figuring out where the sending machine’s clock was thinking the bit changes were.

Bonus fun depressing asynchrony fact: Whenever your chip samples an asynchronous input there is a chance of the logic getting the change just at the wrong time and entering a meta stable state which is neither high nor low for an arbitrarily long time! The best you can do is minimize the probability and probable duration. So, happy new year, all your computers are just rolling dice billions of times per second.

Thankfully that probability decreases exponentially as you add synchronizer stages, which is what you do for clock domain crossing :-). Two synchronizer stages will give you an MTBF on the order of the square of the age of the universe, by one ballpark calculation I found. This obviously goes down as you do it in parallel many times, but still, we're pretty safe here in practice.

I clearly remember having modified/written an FPGA logic analyzer that ended up entering impossible logic lockup states after a few minutes/seconds (Hardware, crashing? What?)... that was when I learned about metastability. Some synchronizers took care of the problem.

It's easier to generate the clock signal, because other wise the little pio state machines in the rp2040 would have to synchronize with the external clock, and that would cut into max clock speed (and probably put something like this outside the realm of possibility). This is because the rp2040's pio doesn't have a way to latch from an external clock.

The main reason I did it that way was to have the RMII TX start sequence generated by the PIO program, and to have a loop to output the data I'd need double the frequency of the RMII, so I had to clock it at 100MHz. So either injecting the 50MHz clock from the LAN8720 into the XIN of the RP2040 and removing the crystal there, or moving around 2 resistors on the PHY module.

I could have used the 50MHz output from the PHY module and inject it into the XTAL input of the RP2040 to feed the PLL and run the MCU at a higher frequency, but it was much easier to do it the other way around by removing a resistor and moving another one on the PHY module

Could this be turned into a USB Ethernet adapter for regular computers?

Almost certainly.

Yeah, but standard pico usb is slow (it has usb 1.1 with 12Mbit/s or even 1.5Mbit/s). BUT you could add separate usb 2.0 phy, but AFAIK it would have to share some pins with that ethernet phy, but still doable.

Never looked at USB 2.0 phy, but you can move any pins used by the eth phy, so I don't see why you would have to share pins between the two.

I remembered bad, ULPI uses only 12 lines, not 20, so you could easily add it without sharing pins.

It certainly could but with awful performance. This is just a proof of concept and no one should do this save to experiment with low level Ethernet.

You're far better off starting with a micro controller that features USB and Ethernet built in, of which there are MANY.

If you want Ethernet on your pi pico, use an SPI Ethernet controller such as the Microchip LAN9250.

To be fair, LAN9250s generally also have awful perf in the same ballpark.

Reply on news.ycombinator.com