5 ms·

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

84 points by mborges 5y ago

mbreese 5y ago
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.
- jrockway 5y ago
  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/src/rmii_ethernet.c#L103 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.)
  - monocasa 5y ago
    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/src/rmii_ethernet_phy_tx.pio https://github.com/maximeborges/pico-rmii-ethernet/blob/main...
    - jrockway 5y ago
      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 :)
- jws 5y ago
  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.
  - marcan_42 5y ago
    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.
    - deleted 5y ago
      [deleted]
- monocasa 5y ago
  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.
  - mborges 5y ago
    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.
- mborges 5y ago
  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
sigjuice 5y ago
Could this be turned into a USB Ethernet adapter for regular computers?
- monocasa 5y ago
  Almost certainly.
- yetihehe 5y ago
  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.
  - mborges 5y ago
    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.
    - yetihehe 5y ago
      I remembered bad, ULPI uses only 12 lines, not 20, so you could easily add it without sharing pins.
- MisterTea 5y ago
  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.
  - monocasa 5y ago
    To be fair, LAN9250s generally also have awful perf in the same ballpark.

84 points by mborges 5y ago

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.

jrockway 5y ago
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/src/rmii_ethernet.c#L103 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.)
- monocasa 5y ago
  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/src/rmii_ethernet_phy_tx.pio https://github.com/maximeborges/pico-rmii-ethernet/blob/main...
  - jrockway 5y ago
    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 :)
jws 5y ago
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.
- marcan_42 5y ago
  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.
  - deleted 5y ago
    [deleted]
monocasa 5y ago
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.
- mborges 5y ago
  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.
mborges 5y ago
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

sigjuice 5y ago

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

monocasa 5y ago
Almost certainly.
yetihehe 5y ago
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.
- mborges 5y ago
  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.
  - yetihehe 5y ago
    I remembered bad, ULPI uses only 12 lines, not 20, so you could easily add it without sharing pins.
MisterTea 5y ago
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.
- monocasa 5y ago
  To be fair, LAN9250s generally also have awful perf in the same ballpark.