4 ms·

Can someone explain to me what I'm looking at it?

formerly_proven 4y ago
10BASE-T = 10 Mbit/s Ethernet. 10G/2.5G/1G/100 Ethernet are all backwards compatible so 10BASE-T is the slowest/simplest Ethernet standard that you can implement today and just plug into just about anything. This is transmit only, so it's pretty much limited to broadcasts (can't do ARP). That's good enough for e.g. sensors.
- LAC-Tech 4y ago
  I need more context. Is a micro-controller able to broadcast through an ethernet port something remarkable? Obviously this upvoted enough that it's causing a buzz, but I'm not an embedded guy and don't really understand why.
  - baq 4y ago
    yes, because it's implemented 100% in software, no dedicated computing/networking hardware (resistors don't count)
  - actionfromafar 4y ago
    It's not through an Ethernet port, that's the interesting part. :)
  - ZiiS 4y ago
    "Micro-controller" is a very wide term. Today it is applied to many things that would have been a good desktop computer only 20 years ago. As you surmise it is not at all impressive that they can talk on the network (may have hardware that fully supports current generation wired and wireless networking) The Pi Pico is quite a simple micro controller, similar to the 1980s hardware that would have actually used 10BASE-T. The impressive bit is it fully software except 3 resistors; rather then having dedicated hardware.
  - magicalhippo 4y ago
    > Is a micro-controller able to broadcast through an ethernet port something remarkable? Many microcontrollers, especially higher-end ones, have built-in dedicated hardware, called peripherals[1], to handle complex and/or high-speed interfaces like Ethernet. The Pico does not have an Ethernet peripheral, so this project relies on bit-banging[2], a brute-force approach to IO. However, the Pico does have the PIO[3], which is a general-purpose IO peripheral, so it's not pure bit-banging in the traditional sense. While it's cute, it's not super remarkable. People have done bit-banged HDMI[4] on the Pico for example. However, Ethernet access can be very useful in a Pico project. [1]: https://electronicguidebook.com/what-are-microcontroller-peripherals/ https://electronicguidebook.com/what-are-microcontroller-per... [2]: https://en.wikipedia.org/wiki/Bit_banging https://en.wikipedia.org/wiki/Bit_banging [3]: https://hackspace.raspberrypi.com/articles/what-is-programmable-i-o-on-raspberry-pi-pico https://hackspace.raspberrypi.com/articles/what-is-programma... [4]: https://github.com/Wren6991/PicoDVI https://github.com/Wren6991/PicoDVI
  - unwind 4y ago
    If the controller is $1 and lacks actual support, and no external network hardware is being used: yes.
  - jmiskovic 4y ago
    I find remarkable how simple it appears to be. You could take any existing Pico-based board, find two unused pins and solder on those four components. You update the software and suddenly the project is network-connected! For most other micro controllers this would either be impossible (dedicated pin already occupied with another function), or would require installing another PCB.
- pezezin 4y ago
  > 10G/2.5G/1G/100 Ethernet are all backwards compatible Not always. The physical layers are incredibly different, and while it is true that most 1G devices also support 10M/100M, we found the hard way that some 10G switches and NICs don't.
  - willis936 4y ago
    10G no, but all 1000BASE-T NICs require autonegotiation for 10/100/1000 to be compliant.
    - Jaruzel 4y ago
      NICs maybe, but there's a whole heap of cheap home switches and hubs that don't support 10BaseT. I know this from experience.
      - Sebb767 4y ago
        I've also experienced some quite expensive Juniper DC switches not supporting anything below 1Gbit. Fun times.
      - dicknuckle 4y ago
        Some ISP core stuff too.
- salmo 4y ago
  I don’t think the other specs are necessarily backwards compatible. The NICs on each end negotiate the fastest commonly supported spec. I’ve had 10G cards that would only negotiate down to 1G or only do 10G. But those were over Twinax. I’ve never use 10G on twisted pair. Back in my day we were excited about 100Base-T and called it Fast Ethernet :). Oooh! Now do 10Base2!
  - thrtythreeforty 4y ago
    Can confirm, we have a bunch of $10 switches lying around our million dollar lab because nobody thought to check if the 40Gbit switches can do 100Mbit to talk to Raspberry Pis. Not sure if we're ever pushing 40Gbit but I know we use the hell out of the RPis. Go figure...
vbezhenar 4y ago
Usually Ethernet support requires some dedicated modules. It's possible to implement protocols with "big-bang". MCU have Analog-Digital-Converters (which allows to measure voltage on selected pin) and Digital-Analog-Converters (which allows to produce a signal of some voltage on selected pin). Basically signals on line are analog and your software is digital. You use ADC to receive signal and DAC to send signal. Then those recorded voltages have to be translated to actual protocol. Bit-banging low-speed protocols is easy. When your MCU does 8 million operations/second and you need to measure 1000 times/second, no problem. You usually use dedicated modules even for low-speed protocols, but that's basically convenience and lower power consumption. Bit-banging high-speed protocols is not easy and usually not possible. 10 Mbit ethernet is 10 million bits per second. So it's almost always requires external modules which implement this protocol in hardware and provide some high-level interface to MCU. Rpi Pico MCU has an interesting feature called PIO. It's basically a dedicated module with some extremely simplified assembly support. It works independently from the MCU cores. People implement various kinds of protocols using bit-banging with PIO. Basically if you don't care about power, you can theoretically save some money by not including an ethernet module in your device, but rather implementing things with bit-banging. Or it might be an interesting experience for someone who implemented it. Usually in reality you just buy STM32 with ethernet support and let it deal with all the protocol intricancies.
- jmiskovic 4y ago
  I like this explanation, but the first paragraph mixes up things. ADCs (and sometimes DACs) are parts of most micro-controllers, but those are never used for digital communication. The most low-level primitive is GPIO block (general purpose input/output). This block can be found on most of chip pins, and it does the conversion between analog voltage and digital bit (as well as value latching and some other functions). With just them and the CPU you could manually receive and send digital bits and build complete communication protocols in software. Also even if your STM32 has ethernet support, you still need a PHY transceiver that accesses the physical medium (wire or optical bus). This project implements both inside the Pico and requires just 3 external resistors. Very impressive feat of engineering, but not something you'd deliver as a field product.
magicalhippo 4y ago
You're looking at a Raspberry Pi Pico which has been hooked up with a make-shift differential driver[1] using two GPIO's[2] where one outputs the inverse signal of the other. The differential signal is connected directly to a RJ-45 jack, which is why the warning about not connecting Power over Ethernet[3] gear is written in bold as it would destroy the Pi. Normally Ethernet is AC coupled[4] through transformers, though capacitors can be used[5], which protects the local device from any DC voltage on the transmission line. Power over Ethernet exploits this by explicitly feeding a DC voltage over the lines. That voltage is way above what the GPIO's on the Pico can tolerate, and would cause the Pico to relase the magic smoke[6]. Not having any AC coupling on the Pico works for short cables if the other side is properly AC coupled. The scope plots shows the differential signal as driven by the Pico. Ethernet is Manchester encoded[7], a self-clocking signal without DC component, which makes it easy to AC couple. The fixed preamble used by Ethernet is so the receiver can recover the clock signal used by the sender in order to correctly read the incoming signal. Using a self-clocking encoding means the senders clock pulses doesn't have to be sent as a separate signal. What you don't see is any way to receive data. As noted this is the bare bones needed to send data. [1]: https://en.wikipedia.org/wiki/Differential_signalling https://en.wikipedia.org/wiki/Differential_signalling [2]: https://en.wikipedia.org/wiki/General-purpose_input/output https://en.wikipedia.org/wiki/General-purpose_input/output [3]: https://en.wikipedia.org/wiki/Power_over_Ethernet https://en.wikipedia.org/wiki/Power_over_Ethernet [4]: https://www.intel.com/content/www/us/en/docs/programmable/683073/current/ac-versus-dc-coupling.html https://www.intel.com/content/www/us/en/docs/programmable/68... [5]: https://ww1.microchip.com/downloads/en/AppNotes/ANLAN120-UNG.pdf https://ww1.microchip.com/downloads/en/AppNotes/ANLAN120-UNG... [6]: https://en.wikipedia.org/wiki/Magic_smoke https://en.wikipedia.org/wiki/Magic_smoke [7]: https://en.wikipedia.org/wiki/Manchester_code https://en.wikipedia.org/wiki/Manchester_code
userbinator 4y ago
"Software Defined Ethernet"

10BASE-T = 10 Mbit/s Ethernet. 10G/2.5G/1G/100 Ethernet are all backwards compatible so 10BASE-T is the slowest/simplest Ethernet standard that you can implement today and just plug into just about anything. This is transmit only, so it's pretty much limited to broadcasts (can't do ARP). That's good enough for e.g. sensors.

LAC-Tech 4y ago
I need more context. Is a micro-controller able to broadcast through an ethernet port something remarkable? Obviously this upvoted enough that it's causing a buzz, but I'm not an embedded guy and don't really understand why.
- baq 4y ago
  yes, because it's implemented 100% in software, no dedicated computing/networking hardware (resistors don't count)
- actionfromafar 4y ago
  It's not through an Ethernet port, that's the interesting part. :)
- ZiiS 4y ago
  "Micro-controller" is a very wide term. Today it is applied to many things that would have been a good desktop computer only 20 years ago. As you surmise it is not at all impressive that they can talk on the network (may have hardware that fully supports current generation wired and wireless networking) The Pi Pico is quite a simple micro controller, similar to the 1980s hardware that would have actually used 10BASE-T. The impressive bit is it fully software except 3 resistors; rather then having dedicated hardware.
- magicalhippo 4y ago
  > Is a micro-controller able to broadcast through an ethernet port something remarkable? Many microcontrollers, especially higher-end ones, have built-in dedicated hardware, called peripherals[1], to handle complex and/or high-speed interfaces like Ethernet. The Pico does not have an Ethernet peripheral, so this project relies on bit-banging[2], a brute-force approach to IO. However, the Pico does have the PIO[3], which is a general-purpose IO peripheral, so it's not pure bit-banging in the traditional sense. While it's cute, it's not super remarkable. People have done bit-banged HDMI[4] on the Pico for example. However, Ethernet access can be very useful in a Pico project. [1]: https://electronicguidebook.com/what-are-microcontroller-peripherals/ https://electronicguidebook.com/what-are-microcontroller-per... [2]: https://en.wikipedia.org/wiki/Bit_banging https://en.wikipedia.org/wiki/Bit_banging [3]: https://hackspace.raspberrypi.com/articles/what-is-programmable-i-o-on-raspberry-pi-pico https://hackspace.raspberrypi.com/articles/what-is-programma... [4]: https://github.com/Wren6991/PicoDVI https://github.com/Wren6991/PicoDVI
- unwind 4y ago
  If the controller is $1 and lacks actual support, and no external network hardware is being used: yes.
- jmiskovic 4y ago
  I find remarkable how simple it appears to be. You could take any existing Pico-based board, find two unused pins and solder on those four components. You update the software and suddenly the project is network-connected! For most other micro controllers this would either be impossible (dedicated pin already occupied with another function), or would require installing another PCB.
pezezin 4y ago
> 10G/2.5G/1G/100 Ethernet are all backwards compatible Not always. The physical layers are incredibly different, and while it is true that most 1G devices also support 10M/100M, we found the hard way that some 10G switches and NICs don't.
- willis936 4y ago
  10G no, but all 1000BASE-T NICs require autonegotiation for 10/100/1000 to be compliant.
  - Jaruzel 4y ago
    NICs maybe, but there's a whole heap of cheap home switches and hubs that don't support 10BaseT. I know this from experience.
    - Sebb767 4y ago
      I've also experienced some quite expensive Juniper DC switches not supporting anything below 1Gbit. Fun times.
    - dicknuckle 4y ago
      Some ISP core stuff too.
salmo 4y ago
I don’t think the other specs are necessarily backwards compatible. The NICs on each end negotiate the fastest commonly supported spec. I’ve had 10G cards that would only negotiate down to 1G or only do 10G. But those were over Twinax. I’ve never use 10G on twisted pair. Back in my day we were excited about 100Base-T and called it Fast Ethernet :). Oooh! Now do 10Base2!
- thrtythreeforty 4y ago
  Can confirm, we have a bunch of $10 switches lying around our million dollar lab because nobody thought to check if the 40Gbit switches can do 100Mbit to talk to Raspberry Pis. Not sure if we're ever pushing 40Gbit but I know we use the hell out of the RPis. Go figure...

vbezhenar 4y ago

Usually Ethernet support requires some dedicated modules. It's possible to implement protocols with "big-bang". MCU have Analog-Digital-Converters (which allows to measure voltage on selected pin) and Digital-Analog-Converters (which allows to produce a signal of some voltage on selected pin). Basically signals on line are analog and your software is digital. You use ADC to receive signal and DAC to send signal. Then those recorded voltages have to be translated to actual protocol. Bit-banging low-speed protocols is easy. When your MCU does 8 million operations/second and you need to measure 1000 times/second, no problem. You usually use dedicated modules even for low-speed protocols, but that's basically convenience and lower power consumption. Bit-banging high-speed protocols is not easy and usually not possible. 10 Mbit ethernet is 10 million bits per second. So it's almost always requires external modules which implement this protocol in hardware and provide some high-level interface to MCU. Rpi Pico MCU has an interesting feature called PIO. It's basically a dedicated module with some extremely simplified assembly support. It works independently from the MCU cores. People implement various kinds of protocols using bit-banging with PIO. Basically if you don't care about power, you can theoretically save some money by not including an ethernet module in your device, but rather implementing things with bit-banging. Or it might be an interesting experience for someone who implemented it. Usually in reality you just buy STM32 with ethernet support and let it deal with all the protocol intricancies.

jmiskovic 4y ago
I like this explanation, but the first paragraph mixes up things. ADCs (and sometimes DACs) are parts of most micro-controllers, but those are never used for digital communication. The most low-level primitive is GPIO block (general purpose input/output). This block can be found on most of chip pins, and it does the conversion between analog voltage and digital bit (as well as value latching and some other functions). With just them and the CPU you could manually receive and send digital bits and build complete communication protocols in software. Also even if your STM32 has ethernet support, you still need a PHY transceiver that accesses the physical medium (wire or optical bus). This project implements both inside the Pico and requires just 3 external resistors. Very impressive feat of engineering, but not something you'd deliver as a field product.

magicalhippo 4y ago

You're looking at a Raspberry Pi Pico which has been hooked up with a make-shift differential driver[1] using two GPIO's[2] where one outputs the inverse signal of the other. The differential signal is connected directly to a RJ-45 jack, which is why the warning about not connecting Power over Ethernet[3] gear is written in bold as it would destroy the Pi. Normally Ethernet is AC coupled[4] through transformers, though capacitors can be used[5], which protects the local device from any DC voltage on the transmission line. Power over Ethernet exploits this by explicitly feeding a DC voltage over the lines. That voltage is way above what the GPIO's on the Pico can tolerate, and would cause the Pico to relase the magic smoke[6]. Not having any AC coupling on the Pico works for short cables if the other side is properly AC coupled. The scope plots shows the differential signal as driven by the Pico. Ethernet is Manchester encoded[7], a self-clocking signal without DC component, which makes it easy to AC couple. The fixed preamble used by Ethernet is so the receiver can recover the clock signal used by the sender in order to correctly read the incoming signal. Using a self-clocking encoding means the senders clock pulses doesn't have to be sent as a separate signal. What you don't see is any way to receive data. As noted this is the bare bones needed to send data. [1]: https://en.wikipedia.org/wiki/Differential_signalling https://en.wikipedia.org/wiki/Differential_signalling [2]: https://en.wikipedia.org/wiki/General-purpose_input/output https://en.wikipedia.org/wiki/General-purpose_input/output [3]: https://en.wikipedia.org/wiki/Power_over_Ethernet https://en.wikipedia.org/wiki/Power_over_Ethernet [4]: https://www.intel.com/content/www/us/en/docs/programmable/683073/current/ac-versus-dc-coupling.html https://www.intel.com/content/www/us/en/docs/programmable/68... [5]: https://ww1.microchip.com/downloads/en/AppNotes/ANLAN120-UNG.pdf https://ww1.microchip.com/downloads/en/AppNotes/ANLAN120-UNG... [6]: https://en.wikipedia.org/wiki/Magic_smoke https://en.wikipedia.org/wiki/Magic_smoke [7]: https://en.wikipedia.org/wiki/Manchester_code https://en.wikipedia.org/wiki/Manchester_code

userbinator 4y ago

"Software Defined Ethernet"