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.
Plus this way you can hook up a couple extra GPIOs and make the lights blink when the magic is happening.
I'm not old enough to have liven when 10BASE-T was mainstream.
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.
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.
..because, now, YOU can whip up the Receive end, eh? ;-)
https://www.youtube.com/watch?v=mwcvElQS-hM https://www.youtube.com/watch?v=m4f4OzEyueg&t=0s
Pretty amazing!
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.
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.
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.
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..
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.
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.
AM335X has PRUs yes, but it's not MCU anymore.
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.
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.
This is transmit only, so it's pretty much limited to broadcasts (can't do ARP). That's good enough for e.g. sensors.
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.
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!
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.
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...
So it's resistor.
This seems to be SFP with Raspberry Pico.
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.
[1]: https://www.instructables.com/Arbitrary-Wave-Generator-With-...
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.
