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.
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.
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.
Video codecs are a really good example of this too. We went from slow and unreliable video decoding in the CPU, to fully offboard / unsupervised decoders (remember the 90s MPEG-2/DVD players that would just blit onto a green part of the screen, where your computer never actually saw the data off the disc?), to CPU/firmware supervised custom hardware (Apple's decoder, for example, uses firmware on a Cortex to lower decoding commands into an IR which runs on custom execution units). With RISC-V making it cheap to add custom instructions, I wouldn't be surprised to see video decoding move to on-chip RISC-V cores with custom instruction set extensions.
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.
I'm confused. Why is there gnuradio on the screen? The RPI seems to have power (micro usb), TX (two wires to the ethernet port on the laptop), and ... what is the third thing?
A RPi 4/5 has that? The OMAP 3/4 chips in Beaglebone is another alternative. Or Rockchip/Allwinner SoCs. Those are all Cortex A series though, but that can still be programmed bare metal if one wants. There are also Cortex M microcontrollers with support for SDRAM, like STM32H7. Or one can get an FPGA with DDR support like ECP5.
This would be a great starting point to make a USB Ethernet NIC if someone were inclined to do it.
It could even have a very practical use if it were made to impersonate a USB Ethernet device that the Nintendo Switch / Nintendo Switch 2 supports. They only support gigabit NICs, but it should be easy to just pretend that the other side failed to negotiate gigabit and only supports 100Mbps.
23 comments
[ 2.7 ms ] story [ 50.6 ms ] threadIt 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.
* 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.
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.
RGMII uses 4-bit bus, so that would be 250M state transitions per second.
Clock signal is 125MHz, yes. But data is sent/sampled at both edges (DDR), so PIO state machine has to be clocked at 250MHz.
That's still reachable with mild overclocking, I guess?
But where would be the fun in that?
Per Siemens? I'd prefer Ohm!
It could even have a very practical use if it were made to impersonate a USB Ethernet device that the Nintendo Switch / Nintendo Switch 2 supports. They only support gigabit NICs, but it should be easy to just pretend that the other side failed to negotiate gigabit and only supports 100Mbps.
> this is a transmit-only proof of concept.
So a not-very-useful NIC for your Nintendo switch.