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.
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.
DACs and ADCs are frequently used for digital communication - for anything RF/wireless they are a key part! Some high-speed SerDes receiver designs are even digitising using fast ADCs and DSP techniques internally now to do things like equalisation in the digital domain too, which is interesting (e.g. [1], [2]). Previously, slower (like 25Gbps and less) SerDes have tended to be purely analogue circuits until near the very end.
I think the GP meant that you wouldn't normally want to try to use an ADC for digital communication because the general-purpose ADCs in, e.g. microcontrollers are either overkill (10 bits just to detect a level!?) or too slow (max sampling rate) to do high-performance I/O. You'd be better off using an existing protocol with just two voltage levels and the GPIO pins. You can make an analog circuit to transform the two voltage levels you do have into the (typically 0-5V) levels detected by the GPIO on the microcontroller.
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.
> 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.
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...
> 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.
"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.
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.
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.
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.