10BASE-T using Raspberry Pi Pico with 2 GPIO pins
github.comA 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.
You could use opto-couplers too for isolation.
Or capacitors, as well.
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.
Optocouplers tend to be quite slow. Transformers are the best option.
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.
A simple DIY transform is shown later in the article, though the first pic in the article shows it without the transformer.
I read the this as 10GBASE-T and for a brief moment in time my whole world turned upside down.
Yeah, I was shocked when I first read it, and then reread seeing no G.
I'm not old enough to have liven when 10BASE-T was mainstream.
Lol these youngsters with their little plastic plugs. 10Base5 is where it's at. Or 10Base2 if you want to be cool.
Intended as /s but I actually still have some stuff here that I need to use a 10BaseT AUI transceiver on :) I love old hardware.
I have a 10base-5 AUI on my desk. Makes an interesting conversation piece now and then.
I’d you haven’t used a drill to attach a computer to a network, you can’t appreciate how easy things are these days…
10BASE-T1 is becoming quite popular with industrial / sensor networks these days.
I remember when 10BASE-T was brand new and hilariously fast and radically better than the clumsy, bulky connectors and cables that had preceded it.
Is that the one that used the nasty vampire taps, or am I thinking older.
-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.
That was 10BASE5 aka thicknet: https://en.wikipedia.org/wiki/10BASE5
Same.
But still... 10BASE-T with 2 wires is a hell of an achievement..
Now 10GBASE-T with two wires, is the "Dark Souls on Bongo Drums" of networking.
10GBASE-T1 does actually exist! It's an automotive standard like 1000BASE-T1
10BASE-T only uses 2 wires to xmit doesn't it?
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.
There is also 10BASE-T1 and 100BASE-T1 which only requires a single twisted pair for transmit and receive.
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."
https://www.marvell.com/content/dam/marvell/en/public-collat...
ez just use PAM4 signaling
(/s)
Yes, and 100BASET as well.
A "Fresh prince" moment.
Exactly the same. I read it as 10GBASE-T and my eyebrows hit my ceiling.
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.
Ahem. CSMA/CD. 10BaseT implies wired connection.
I think I'd rather have such a project report 'early' than wait till it's supporting a web server via those 2 pins...
..because, now, YOU can whip up the Receive end, eh? ;-)
/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.
cnlohr did something similar with an ATTiny85:
https://www.youtube.com/watch?v=mwcvElQS-hM https://www.youtube.com/watch?v=m4f4OzEyueg&t=0s
Pretty amazing!
Igor Cesko did probably the first widely-known implementation of bit-banged 10BASE-T, in 2004:
https://web.archive.org/web/20110312185808/http://members.ch...
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.
https://www.ic72.com/pdf_file/i/428749.pdf
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.
Doing it on a ATTiny85 is a lot more impressing than doing it on a "larger" microcontroller :)
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.
[1]: https://en.wikipedia.org/wiki/Video_Graphics_Array#Color_pal...
[2]: https://int10h.org/blog/2015/04/cga-in-1024-colors-new-mode-...
[3]: https://www.reenigne.org/blog/1k-colours-on-cga-how-its-done...
I think you're confused. This is on a Raspberry Pi Pico, which is a microcontroller and has no cache.
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.
A similar thing for the Forth chips produced by Chuck More and colleagues: https://www.greenarraychips.com/home/documents/greg/AN007-14...
Should be able to run CANbus also, here we go, someone did it:
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.
RP2040 is an amazing MCU, I'm unaware of any other similar MCU has a programmable PIO module.
Based on the Ethernet and previous HDMI work done to this chip, I'm to write my own I3C master/slave on it soon, should be doable.
Software peripherals were popular in the nineties when using Scenix 50MHz PIC clones https://hackaday.com/2022/08/17/chips-remembered-the-scenix-...
In 2006 we got 8 core risc chips running at 80MHz. 0.25 IPC = 160MIPS https://en.wikipedia.org/wiki/Parallax_Propeller
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."
https://www.xmos.ai/download/XS1-L16A-128-QF124-Datasheet(1....
2012 TI sitara AM335x (beaglebone black) has dedicated IO cores.
First time heard about Scenix/Prallax_Propeller. Maybe it's more complex for DIYers or not as well-known as Raspberry Pi?
AM335X has PRUs yes, but it's not MCU anymore.
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.
Can someone explain to me what I'm looking at it?
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.
Thanks for this explanation!
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.
10G no, but all 1000BASE-T NICs require autonegotiation for 10/100/1000 to be compliant.
NICs maybe, but there's a whole heap of cheap home switches and hubs that don't support 10BaseT. I know this from experience.
I've also experienced some quite expensive Juniper DC switches not supporting anything below 1Gbit. Fun times.
Some ISP core stuff too.
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!
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...
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.
> 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-per...
[2]: https://en.wikipedia.org/wiki/Bit_banging
[3]: https://hackspace.raspberrypi.com/articles/what-is-programma...
"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.
It's not through an Ethernet port, that's the interesting part. :)
If the controller is $1 and lacks actual support, and no external network hardware is being used: yes.
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.
yes, because it's implemented 100% in software, no dedicated computing/networking hardware (resistors don't count)
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
[2]: https://en.wikipedia.org/wiki/General-purpose_input/output
[3]: https://en.wikipedia.org/wiki/Power_over_Ethernet
[4]: https://www.intel.com/content/www/us/en/docs/programmable/68...
[5]: https://ww1.microchip.com/downloads/en/AppNotes/ANLAN120-UNG...
"Software Defined Ethernet"
Is "register" instead of "resistor" just a typo, or is that word really used in this context?
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.
So it's resistor.
It's a typo, you can clearly see the three resistors in the image as well.
The other repository seems more interesting (can someone translate?) https://github.com/kingyoPiyo/RasPico_SHIBAKI_Board
This seems to be SFP with Raspberry Pico.
Pretty neat. I wonder how much noise those lines can handle.
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.
Sooo, with this you can send ethernet packets from a RPI pico? I wonder at which speeds with this setup only using 2 GPIO's.
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.
[1]: https://www.instructables.com/Arbitrary-Wave-Generator-With-...
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.
10Mb/s - it's 10BASE-T
The fact that it links up at 10BASE-T does not mean that it can send at wire rate.
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.
He'll have to get reception working first :)
LWIP [1] could be used for this. You'd just need to implement I/O.
Was hoping that said 10GB - need a couple 10GB devices for load testing a network lab if anyone has any cheap suggestions :)