A word of caution: this has been done with other uControllers in the past; nothing wrong with it from a functional point of view, but be aware that the lack of transformers means the boards i/o pins aren't insulated from whatever it's connected to them; any wrong connection by mistake or static charges in case of a long cable could damage the chip forever. The best and safest use i can imagine of a transformerless arrangement would be a cluster of Pi Picos all mounted on a backplane containing a Ethernet switch chip; in that situation they would share the same power supply and ground so a simple level translation where necessary would be enough, and probably a total of two wires could be used for transmission and receive since balanced signals wouldn't be needed anymore.
Keep in mind though, that even 10BASE-T works with high enough of a frequency, that you need to think about impedance matching and line termination. And 3 galvanic isolation options (transformer, optocoupler, capacitor) all have very different impedance characteristics. For optocoupler that impedance is moreover voltage-dependent - i.e. that part is non-linear. Yikes. Say hello to harmonics.
Peer comment explained why this is almost certainly a bad choice - not to mention you'd need some pretty specialized optocouplers to even operate at that high a frequency - so I suggest getting a receptacle with integrated magnetics. Ideally on a nice little breakout board like this SparkFun MagJack breakout board. [1]
Plus this way you can hook up a couple extra GPIOs and make the lights blink when the magic is happening.
Yeah. Modern (but not bleeding edge) optocouplers can do 100ns pulses which would give you 10mbps - but I’m not sure how that plays with the failure mode for the transmissions. Ethernet doesn’t care how many packets your sending per second, it’ll try to do the full speed from the get-go, so the question is whether the errors would be exacerbated or alleviated by retransmission from higher up in the stack.
-T indicates "twisted pair". Vampire tap was 10BASE5 (later also called Thick-Ethernet, to contrast with 10Base2 "Thinnet" which used thinner coax and BNC T-pieces)
I never saw 10base5 coax, but I worked in a lab in the day with massive thick 15 pin cables everywhere (AUI?), and 4 port hubs (that is combine 4 computers into one uplink that I supposed eventually went to coax in the ceiling, though I only saw it go to yet another such hub. The office was 10baseT already, but the lab had a lot of older computers.
10BASE-T and 100BASE-T require 2 wires to transmit and 2 wires to receive, 4 wires total. Actually it is better to call them 2 pairs since it's a balanced arrangement in which each pair signals come and go in reverse phase from the interface transformers and wires of each pair are twisted together so that any picked up noise can be canceled out.
1000BASE-T (Gigabit Ethernet) uses all four pairs, that is, all eight wires of a CATx cable.
And, as a earlier poster explained, there is 10GBASE-T1,
which is 10G over a single pair! Wow! Who knew!?
"The 88Q4364 is manufactured using a standard digital CMOS
process and contains all the active circuitry required to
implement the physical layer functions to transmit and receive
data on a single balanced twisted pair."
Oh wow, this is was earlier in development than I was expecting. Literally just banging out the bits on the wire for a UDP packet without any underlying protocol support. No CSMA/CA. No ARP. No autonegotiation. Can't even receive. Just enough support to calculate the checksums and do the Manchester encoding before clocking the bits out on the wire.
/CD requires receiving while transmitting, which is probably going to get really complicated in software when trying to precisely time GPIO pulses at .1us intervals on a 133Mhz CPU. Probably need to add an external latch + carrier sense circuit to assert a collision signal.
Side note, I do love the Firesign Theater reference, Mr. Tirebiter.
Although, one should note that both Igor & Charles did that purely in software, while OP's project is using PIO machinery, so it's strictly speaking not the same thing.
Back in 1999 we built a 100% bit-banged software implementation of 10BASE-T including all of the stack up to UDP & TCP. It was a demonstration project to show off the performance of the 50MHz/50MIPS Scenix microcontroller.
By the time it was commercialized in 2001 the PHY had moved into hardware, but the Ethernet MAC functionality was still software.
It is funny to see now that we named the chip IP2022 ... IIRC I don't think we were thinking that it was so futuristic it represented what the year 2022 would look like.
In some ways it is less though, as the larger CPU on the pi has things like cache that mess with your timing, while with the smaller CPUs you can lookup exactly how long each instruction will take and thus get the timing right. In the end though, both are very impressive, the hardware just gives different challenges to work with.
edit, reading more I realized the pi pico isn't doing this on the main cpu, but on the PIC (which isn't on a normal pi I think). I have no idea what that is able to do, but it changes the above.
> with the smaller CPUs you can lookup exactly how long each instruction will take and thus get the timing right
Reminds me of the good old demo scene hack to get 18-bit color[1] back in the VGA days (and probably earlier) by changing the color palette per pixel through careful timing of the instructions.
IIRC you ignore the pixel values entirely, writing effectively a single "color", ie palette index, and then just change that single palette entry per pixel, timed so it's ready just when the output DAC is clocked to the next pixel.
edit: I forgot which demos I've seen this effect in, but searching for it led me down a marvelous rabbit hole where I stumbled over someone[2] managed[3] to get 1k colors over CGA[4], apparently discussed here[5] a couple of years ago.
It's still a hell of a lot more powerful than an attiny85 though which is only an 8 pin micro for the smallest stuff. I love those little things and I used them all the time until most stuff became connected and the esp8266 was more useful because of its wi-fi.
This is also possible using GPIOs on an FPGA as well. Have a look over at FPGA4Fun: https://www.fpga4fun.com/10BASE-T.html 10base-T is such a simple protocol, and implementing it is a good way to learn many of the physicaly layer fundamentals of Ethernet.
The funniest Ethernet system I've seen is that used in dataprobe's "iBoot" remote power switch. These used 8051 microcontroller (the classic 40-pin DIP) connected to an ISA-bus FIFO-based 10/100 Ethernet chip using GPIOs. The FIFO saves you since the 8051 doesn't have to keep up with the line rate (one whole packet has to fit in the FIFO).
But I know these devices fail when the network is chatty- like if you have spanning-tree enabled.
The iBoot has a simple web interface. Somebody wrote an entire network stack for 8051..
Hooking up an ISA Ethernet card (or chips designed to go into one) to an 8051 (and later, AVR) was actually the go-to way to do "internet of things" back in the day. Then ENC28J60 came along, and things got much easier.
in 2008 XMOS xCORE came out, instead of 8 cores in parallel you get 1-2 CPU tiles running at 400-500MHz partitioned into 4-16 virtual cores. 1 IPC = 1000MIPS. 1 cycle IO. Super popular in audio devices where it bitbangs all sort of serial audio interfaces while performing DSP. Newer models have DSP instructions, and the newest ones might even have something for NNs.
"Each tile has 8 active logical cores, which issue instructions down a shared four stage pipeline. Instructions from the active cores are issued round-robin. If up to four logical cores are active, each core is allocated a quarter of the processing
cycles."
You can often do similar things with timers and dma or a serial device. It isn’t as easy as the PIO model is more familiar for people who are used to thinking in terms of code running, but timers in combination with gpio can be crazy powerful.
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.
I think it's a typo from japanese. I think 'register' and 'resistor' can be written the same or very similar in katakana ( レジスター ) and it can be confusing.
The transformer-coupling of Ethernet isn't a trivial fact.
When building precision instrumentation, I was extremely happy to learn about this from one of our old-timers who had been working on systems since the days of the VAX.
You need not worry about DC ground-loops with Ethernet.
When I saw the post-title, I thought, "oh, no, what about the transformer-coupling?". Was very happy to see a simple technique outlined in the article.
Using the PIO you can get some serious speed out of it. Someone made an arbitrary waveform generator[1] reaching 125Msps stock, for example. But you can overclock[2] the Pico up to 420MHz apparently so maybe you can get even more, though not sure if the GPIO drivers can handle that though.
If you want to communicate with standard Ethernet gear, that would be either 10Mbit/s exactly (10BASE-T standard) and 100Mbit/s exactly (100BASE-TX standard).
OP implemented 10BASE-T here. Next step up is 100BASE-TX, which nobody did in software/bit-bang as of yet, as far as I'm aware - part of the reason it's fairly large jump in complexity. Namely, you'd need 3 analog voltage levels, as well as pretty hairy digital scrambling/encoding, to output 100BASE-TX. RPi-pico might just be able to eek that out with few external resistors and enough elbow grease.
Other reason nobody bothered with bit-bang 100BASE-TX - virtually all switches will happily down-negotiage to 10BASE-T, which gives you ~1.2MB/s, and that's plenty fast enough for a microcontroller with mere kilobytes of RAM.
That's exactly what it means. But if you didn't know that you can look at the last oscilloscope screenshot; as you can see, it's set to 200 nanoseconds per division, and it's pumping out bit transitions quite precisely every 50 nanoseconds, and 10BaseT uses Manchester encoding, so that gives you 10 megabits per second.
I think GP might mean what sort of data throughput would be achievable, but that's also trivially 10Mbps with suitably trivial data, and sending easier than non->/dev/null rx.
Really more a question of what you try to make it do with the link, but it would be fun to see it do some very basic routing/firewalli g for example.
