this is classic computing wheel of life stuff (Bell, Mudge, MacNamara wrote that up in the 70s)
* first you do it in the cpu
* then you do it in a dedicated card off the bus
* then you find the FPGA or whatever too slow, so you make the card have it's own CPU
* then you wind up recursing over the problem, implementing some logic in a special area of the cpu, to optimise its bus to the other bus to ...
I expect to come back in 10years and find there is a chiplet which took the rpi core, and implements a shrunk version which can be reprogrammed, into the chiplet on the offload card, so we can program terabit network drivers with a general purpose CPU model.
Fun stuff. You kids don't know how lucky you are to have really capable MCU's for just a few bucks. :-)
It is kind of the ultimate "not a TOE[1]" example yet.
[1] TOE or TCP Offload Engine was a dedicated peripheral card that implements both the layer 1 (MAC), layer 2 (Ethernet), and layer 3 (IP) functions as a co-processing element to relieve the 'main' CPU the burden of doing all that.
Sometimes it goes the other direction. PCI SSL accelerator cards were a thing for a long time before CPUs got faster, got various crypto acceleration opcodes, web servers rewrote SSL logic in ASM, etc.
On a Pico? No - the PIOs replace other peripherals a µC might be able to use to achieve this sort of bitrate, so you'd not really have the tools you'd need to change GPIO pin states once every 3-4 CPU clock cycles.
In a sense the PIO is a bit 'cheaty' when claiming "bit-banging", because the PIO is the ultimate peripheral, programmable to be whatever you need. It's no mean feat to make the PIO do the sorts of things happening here, by any stretch, but "bit-banging" typically means using the CPU to work around the lack of a particular peripheral.
From that perspective, there's precious few µCs out there that could bit-bang 100MBit/s Ethernet - I'm no expert, but I _think_ that's a 125MHz IO clock, so if you want 4 CPU cycles per transition to load data and push it onto pins, you're looking for a 500MHz µC, and at those speeds you definitely have to worry about the bus characteristics, stalls, caching, and all those fun bits; it's not your old 8-bit CPU bit-banging a slow serial protocol over the parallel port any more.
This is significant. It's using a hardware peripheral that is designed and intended for high frequency IO manipulation without CPU intervention. This isn't bit-banging, lest we start calling it "bit-banging" any time an FPGA or ASIC or even a microcontroller peripheral handles any kind of signalling.
Technically it's running software on the programmable I/O, but that software is just a loop of four outputs that advances when it gets a 1 bit and doesn't advance when it gets a 0 bit. It feels like the hardware that manages the buffer and turns it into a high speed serial stream is doing the more important work here.
And the CPU that's actually deciding on the bits doesn't have to bang them with precise timing, it just has to put them into that buffer.
but Yes on pico2 because RP2350 has separate fast serializer (HSTX) hardware block able to clock out at 2x the global clock (DDR). 320MHz OC results in 600Mbit output. Here example pumping out 175 MByte/s of data encoded as HDMI signal (3 lanes) without touching PIOs https://github.com/steve-m/hsdaoh-rp2350 to be used with $6 MS2130 USB 3.0 4k HDMI Video Capture dongle.
Ehhhhh the picture shows a very short cable. You can most certainly find micros that can run 100Mb/s communication interfaces, though sure maybe not bitbanged. However, you really need a PHY and magnetics. MII is 25MHz which seems fine. GMII is 125 MHz SDR which is something. Honestly that would've been a cooler demo IMO than running 2 inches
Not at that transfer rate. SPI which is the next fastest (common) protocol you find on micros typically operates around 10 Mhz, but this isn’t an apples to apples comparison.
Sadly 100Mbit might be the limit for bitbanging ethernet. While 1Gbit uses easily reachable 125MHz clock it also does full duplex requiring echo cancellation and I dont see an easy way around external PHY. The next PICO challenge is implementing GRMII PHY support for that sweet $1 RTL8211 1Gbit. I havent seen that done yet.
PIO is a set of coprocessors designed to offload signal processing. They have to be programmed. PSoC has FPGA like configuration capabilities, but rather than just logic gates it includes larger analog and digital ICs. You can route analog signal processing in and out without hitting a CPU and perform some FPGA like DSP driven by an arbitrary clock signal (also without any CPU usage).
PIO is great but the competition has working silicon and SDK for all of the common peripherals while RP gives you crappy example code. Want to connect to an audio codec with I2S? Almost every MCU has this built in but for RP2040/RP2350 you'll have to roll your own production quality version from a demo that only shows how to send. Years after release.
The RP2040 has great documentation and the PIO is an amazing swiss army knife of a peripheral. I've had no trouble learning from their datasheet and docs and making plenty of PIO programs.
* first you do it in the cpu * then you do it in a dedicated card off the bus * then you find the FPGA or whatever too slow, so you make the card have it's own CPU * then you wind up recursing over the problem, implementing some logic in a special area of the cpu, to optimise its bus to the other bus to ...
I expect to come back in 10years and find there is a chiplet which took the rpi core, and implements a shrunk version which can be reprogrammed, into the chiplet on the offload card, so we can program terabit network drivers with a general purpose CPU model.
It is kind of the ultimate "not a TOE[1]" example yet.
[1] TOE or TCP Offload Engine was a dedicated peripheral card that implements both the layer 1 (MAC), layer 2 (Ethernet), and layer 3 (IP) functions as a co-processing element to relieve the 'main' CPU the burden of doing all that.
In a sense the PIO is a bit 'cheaty' when claiming "bit-banging", because the PIO is the ultimate peripheral, programmable to be whatever you need. It's no mean feat to make the PIO do the sorts of things happening here, by any stretch, but "bit-banging" typically means using the CPU to work around the lack of a particular peripheral.
From that perspective, there's precious few µCs out there that could bit-bang 100MBit/s Ethernet - I'm no expert, but I _think_ that's a 125MHz IO clock, so if you want 4 CPU cycles per transition to load data and push it onto pins, you're looking for a 500MHz µC, and at those speeds you definitely have to worry about the bus characteristics, stalls, caching, and all those fun bits; it's not your old 8-bit CPU bit-banging a slow serial protocol over the parallel port any more.
This is significant. It's using a hardware peripheral that is designed and intended for high frequency IO manipulation without CPU intervention. This isn't bit-banging, lest we start calling it "bit-banging" any time an FPGA or ASIC or even a microcontroller peripheral handles any kind of signalling.
Here, it runs software that allows it to talk 100mbps Ethernet.
Someone else might use that same hardware peripheral to drive a display, or produce a PWM output, or whatever.
The RP PIOs just run software. That software can bang bits.
And the CPU that's actually deciding on the bits doesn't have to bang them with precise timing, it just has to put them into that buffer.
but Yes on pico2 because RP2350 has separate fast serializer (HSTX) hardware block able to clock out at 2x the global clock (DDR). 320MHz OC results in 600Mbit output. Here example pumping out 175 MByte/s of data encoded as HDMI signal (3 lanes) without touching PIOs https://github.com/steve-m/hsdaoh-rp2350 to be used with $6 MS2130 USB 3.0 4k HDMI Video Capture dongle.
I assume passive PoE; or does it also happen to look like a real PoE PD and trick the PSE into turning on?
Sadly 100Mbit might be the limit for bitbanging ethernet. While 1Gbit uses easily reachable 125MHz clock it also does full duplex requiring echo cancellation and I dont see an easy way around external PHY. The next PICO challenge is implementing GRMII PHY support for that sweet $1 RTL8211 1Gbit. I havent seen that done yet.
https://github.com/bschwind/rp2040-i2s/blob/e1d5647704b03ad1...
And I2S input:
https://github.com/bschwind/rp2040-i2s/blob/e1d5647704b03ad1...
The RP2040 has great documentation and the PIO is an amazing swiss army knife of a peripheral. I've had no trouble learning from their datasheet and docs and making plenty of PIO programs.