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.
We start out doing things in the CPU, create dedicated hardware for it externally, then slowly but surely bring it closer and closer to the CPU until we end up integrating the specialist capabilities into it. Often these capabilities enable other workloads to be done in the CPU, that we then build dedicated hardware for and the cycle continues.
An easy example is the 8087 maths coprocessor, from the early 80s. They were floating point accelerators, a separate chip you could plug into your motherboard, until eventually it was integrated into the CPU (386 and 486 processors had SX and DX variants, DX had the coprocessor integrated)
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.
And of course the counterfeit problem has very little to do with what node is used to produce the chips; it's a question of how effective your society's institutions are at keeping fraud under control.
There's the clearly labeled and advertised GD32F103 style clone which is pin-compatible, supports higher clock speeds than the original STM32F103, but takes much longer to power on and has different analog characteristics, maybe some worse; not a problem.
There's the potential case where somebody sells you a GD32 telling you it's an STM32, either with the proper markings, with the markings sanded off, or with actually fake markings. This still might cause no problems, or might result in a problem that takes you a long time to track down. (Maybe you're unknowingly relying on, say, the hypothetical lower power consumption of a clone, so when you fab a
batch with real STM32s, the product's battery life goes to shit.) You can detect this in firmware and may be able to come up with workarounds. Or, if your vendor is FTDI, they may sneak malware into their Microsoft Windows driver and brick your products months or years after you've sold them. They've done it twice.
There's the case where the clone is designed to act as much like the original as possible, so maybe you can't detect the substitution in firmware and can't work around whatever problems the counterfeit is causing.
Then there's the case where you ordered 10,000 STM32s in a QFN-32 and got 10,000 QFN-32s that say "STM32" on them but are actually PICs with a totally different pinout, or SRAM, or something else. These will not probably still work.
This depends on the PIO in the RP2040/RP2350. As far as I know, that is an innovation exclusive to the Raspberry Pi company, so it would not be possible to do this on another microcontroller:
The microcontroller has additional cores called state machines in the PIOs that are specifically designed for bit banging and have their own custom ISA that reportedly only has 9 instructions.
Yes, it does, although it's almost like horizontal microcode; it can do several things in a clock cycle other than the instruction itself. I didn't mean to imply that you could bitbang 100BaseT with a Padauk PFS150 or a PY32.
The Padauk FPPA chips are probably a bit better at bitbanging strange protocols than any ARM, but not in the same class as the Pi's PIO.
After consulting the datasheet, I think the most things you can do in a single pioasm instruction would be a conditional decrementing JMP with side-set, wrap, and delay:
• decrement the X or Y register;
• conditionally jump to a specified target address if it was nonzero;
• otherwise, jump (by "wrapping") to some other specified target address, usually an outer infinite loop;
• change the state of four or less GPIO pins to immediate constants;
• delay 1–15 clock cycles.
Arguably IN can compete here, replacing the first two items with:
• set one or more GPIO pins from bits shifted out of a shift register;
• conditionally "autopull" a 32-bit word from an input FIFO if the shift register is empty;
• conditionally stall the pioasm program if the FIFO is empty;
• conditionally initiate a DMA request to refill the FIFO if it's not full.
The OUT instruction has similar "autopush" capabilities.
Most of these are somewhat independent choices, but if you don't pull from the FIFO you won't have the other effects, and several of the options are state-machine-wide.
>Fun stuff. You kids don't know how lucky you are to have really capable MCU's for just a few bucks. :-)
Any suggestions for people not used to tinkering with hardware? I would like to play I think, but I have a lack of imagination regarding potential projects/goals.
One of my friends got a Pimoroni InkyFrame and was trying to figure out what to do with it. Ended up learning a substantial amount about how dithering works to convert images into the 7 colors the eInk display can produce. It just sits there playing the original Shrek at 1 minute per frame over and over again XD.
When he messed up the color conversion "Green Farquaad" was a recurring meme in our group chat.
I can recommend a 'Hacker Boxes'[1] subscription. It's $44/month currently, every month you'll get all the parts to build some gizmo or project and a full list of instructions. The prerequisites are that you know how to solder and have a soldering iron, and have a computer you can run the Arduino IDE on (even a Raspberry Pi can do that these days).
If you don't know how to solder the Hacker Boxes folks have a soldering workshop kit that includes an iron[2], but many maker spaces will do soldering clinics. Soldering irons are available as cheap[3] and more expensive[4] (and ludicrous[5]). The Arduino IDE runs on pretty much anything (Linux, MacOS, Windows).
you can program it with the USB and the Arduino IDE
most dev boards (that means the MCU is put onto a PCB and you can do stuff with its pins) already have a LED on it so you can blink that without any soldering
they also usually have two tiny buttons one of which doesn't do anything/much and you can use those as input
ESP32 also has built in Wifi and you can make it host a supertiny webserver, or even be its own AP. It also has Bluetooth but I haven't tried that yet.
You can do all these things by asking ChatGPT for the code and instructions :-)
It can do a lot more than this though, but it might inspire you to try other things.
Oh one more very cool thing if you're just getting started is that the ESP32 has 10 pins which are "capacitive touch" sensors and attach a wire to that pin and if you touch the wire, your program gets a signal. This works very well and makes that you can do interactive stuff without even having to solder buttons on anything.
I'd like to hook up a rain sensor to a skylight to close it when it rains (needs a little motor, too), and then also hook it up to weather forecasts.
I currently have to switch on my TV, surround set and a laptop, and then push multiple buttons to switch to/from a firestick. I'd like to automate that, so I can just switch it on/off and switch the source easily. Also if the system is in an unknown state (tv on, but using the incorrect HDMI input and the surround set if switched off, etc.), which is what the naive solution using a "fingerbot" and a IR blaster hooked up to godawful tuya stuff doesn't do.
Build a GPS-synchronized flip clock.
Add remote control door opening without destroying my flat's intercom system.
Mostly kinda boring home automation stuff, but would be worth it for tinkering.
As someone who is only mildly bullish about AI, my hope is that such ultra custom HA will be more common, and no longer limited fo the 0.1% and software engineers.
I can't get my head around it sometimes. I know most end up doing duties that a PIC-chip could do but the fact you can get a WiFi enabled microcontroller few a few bucks blows my mind.
The IO co-processing on the Pico is so powerful, I hope they expand on this.
It's also not really clear that using some of the more powerful chips for simple things is really a "waste" in any reasonable sense of the word. The packaging of a PIC/CH32 is probably the majority of its cost and environmental "footprint".
An RP2040 is not much more physical material.
An ESP8266/ESP32 is rather bit more material, but still not egregious.
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.
The fancy Mellanox NVIDIA Connect-X cards have kTLS support which offloads encryption to the NIC, Netflix has blogged about how they use it to send 100 Gbps encrypted traffic of a single box (Their OpenConnect infrastructure is really cool).
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.
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.
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.
I feel most people would unless you use some Hard IP for the interface. Like you don't bit-bang PCIe when you feed a wide AXI stream at a few MHz into the PCIe block where it get's serialized and put onto the lanes at the signalling rate (multiple Gigahertz, depending on generation).
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.
Intriguing, but I'm referring to the toolchain as a whole. Everything is done with CMake mumbo jumbo that is a pain to set up. For a computer this small and simple there should be a straightforward "compile .c to .o, link .o to flashable binary, flash binary" that any user can type in at the shell or put into a Makefile.
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.
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).
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?
I think it's the signal they're "converting" to ethernet. That'd be the "digitizing some WBFM IF signal with the internal ADC" part. What I don't know is what's in the signal :P
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.
With an external PHY you can use single pair ethernet, which is much more suitable for use in embedded devices. Single pair ethernet directly competes against I2C and CAN, because you only need 2 wires for full duplex 100mbit/1000mbit connectivity.
Single pair ethernet also has the massive advantage that it isn't restricted to the garbage RJ45 plugs, which are basically a nightmare in embedded devices.
Not quite the same but I was looking at PowerBook G4 specs last night. Apple was doing gigabit ethernet in a mid-priced laptop ($2200 in 2001 dollars) 25 years ago. Meanwhile I'm pretty sure I have some 10baseT gear kicking around.
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.
Maybe totally my fault for being dumb, but the ESP32 has an I2S peripheral and after days combing through docs and web searches I never actually got it working, mostly because it seems to have been barely documented and its usage was by twiddling magic registers etc. I’d say personally some nice example PIO code that I can actually read through, understand, and modify for my needs is actually better…
> I’d say personally some nice example PIO code that I can actually read through, understand, and modify for my needs is actually better…
I agree and that's why its disappointing RP still provides half-baked examples instead of real working implementations of the common peripherals other manufacturers are supporting.
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.
Yeah, this is the Wheel of Reincarnation, but wasn't it Sutherland who wrote that up? And Myer? And in 01968? https://www2.cs.arizona.edu/~cscheid/reading/myer-sutherland...
Maybe it was. Bell/mudge/macnamara was the textbook I recalled it from 1979 vintage. I can believe 68 is the original.
I understood some of these words
We start out doing things in the CPU, create dedicated hardware for it externally, then slowly but surely bring it closer and closer to the CPU until we end up integrating the specialist capabilities into it. Often these capabilities enable other workloads to be done in the CPU, that we then build dedicated hardware for and the cycle continues.
An easy example is the 8087 maths coprocessor, from the early 80s. They were floating point accelerators, a separate chip you could plug into your motherboard, until eventually it was integrated into the CPU (386 and 486 processors had SX and DX variants, DX had the coprocessor integrated)
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.
Or just a few cents! Possibly that will only last until war in Taiwan, though, or until it becomes impossible to find anything but counterfeits.
Uncertain. The cheap, mass produced commodity ICs are built with "ancient" nodes with high yields.
I think that's probably true for Padauk's PFS150 and similar, but I think the 14¢ https://www.lcsc.com/product-detail/Microcontrollers-MCU-MPU... and the 9¢ https://www.lcsc.com/product-detail/Microcontrollers-MCU-MPU... are probably fabbed in more recent nodes.
And of course the counterfeit problem has very little to do with what node is used to produce the chips; it's a question of how effective your society's institutions are at keeping fraud under control.
https://zeptobars.com/en/read/wch-ch32v003-risc-v-riscv-micr...
This page estimates 90nm for the CH32V003, and I found another post very roughly estimating 130nm. And a pi pico isn't all that fancy either at 40nm.
And should I be very worried about counterfeit microcontrollers? It seems like a lot of effort, and like it would probably still work.
There are different levels of "counterfeit".
There's the clearly labeled and advertised GD32F103 style clone which is pin-compatible, supports higher clock speeds than the original STM32F103, but takes much longer to power on and has different analog characteristics, maybe some worse; not a problem.
There's the potential case where somebody sells you a GD32 telling you it's an STM32, either with the proper markings, with the markings sanded off, or with actually fake markings. This still might cause no problems, or might result in a problem that takes you a long time to track down. (Maybe you're unknowingly relying on, say, the hypothetical lower power consumption of a clone, so when you fab a batch with real STM32s, the product's battery life goes to shit.) You can detect this in firmware and may be able to come up with workarounds. Or, if your vendor is FTDI, they may sneak malware into their Microsoft Windows driver and brick your products months or years after you've sold them. They've done it twice.
There's the case where the clone is designed to act as much like the original as possible, so maybe you can't detect the substitution in firmware and can't work around whatever problems the counterfeit is causing.
Then there's the case where you ordered 10,000 STM32s in a QFN-32 and got 10,000 QFN-32s that say "STM32" on them but are actually PICs with a totally different pinout, or SRAM, or something else. These will not probably still work.
This depends on the PIO in the RP2040/RP2350. As far as I know, that is an innovation exclusive to the Raspberry Pi company, so it would not be possible to do this on another microcontroller:
https://magazine.raspberrypi.com/articles/what-is-programmab...
The microcontroller has additional cores called state machines in the PIOs that are specifically designed for bit banging and have their own custom ISA that reportedly only has 9 instructions.
Yes, it does, although it's almost like horizontal microcode; it can do several things in a clock cycle other than the instruction itself. I didn't mean to imply that you could bitbang 100BaseT with a Padauk PFS150 or a PY32.
The Padauk FPPA chips are probably a bit better at bitbanging strange protocols than any ARM, but not in the same class as the Pi's PIO.
After consulting the datasheet, I think the most things you can do in a single pioasm instruction would be a conditional decrementing JMP with side-set, wrap, and delay:
• decrement the X or Y register;
• conditionally jump to a specified target address if it was nonzero;
• otherwise, jump (by "wrapping") to some other specified target address, usually an outer infinite loop;
• change the state of four or less GPIO pins to immediate constants;
• delay 1–15 clock cycles.
Arguably IN can compete here, replacing the first two items with:
• set one or more GPIO pins from bits shifted out of a shift register;
• conditionally "autopull" a 32-bit word from an input FIFO if the shift register is empty;
• conditionally stall the pioasm program if the FIFO is empty;
• conditionally initiate a DMA request to refill the FIFO if it's not full.
The OUT instruction has similar "autopush" capabilities.
Most of these are somewhat independent choices, but if you don't pull from the FIFO you won't have the other effects, and several of the options are state-machine-wide.
>Fun stuff. You kids don't know how lucky you are to have really capable MCU's for just a few bucks. :-)
Any suggestions for people not used to tinkering with hardware? I would like to play I think, but I have a lack of imagination regarding potential projects/goals.
"Play" implies a lack of seriousness.
To that end:
1. Blink an LED (this is more rewarding than it seems it should be, because it proves that the toolchain works)
2. Learn to fade that LED on and off instead of blink
3. Learn to make an RGB pixel using red, green, and blue LEDs and some tissue paper
4. Realize that's kind of limiting, and use a WS2812B LED pixel instead
5. Notice that there's whole panels of WS2812B available
6. Buy one. Make it display dumb memes or emojis or dickbutts or whatever.
7. Add a web interface.
8. Give it a domain name.
9. Aim a camera at it, fire up a twitch stream, send the link to HN, and we'll spend a few hours or days shitposting on your little video wall
10. ???
11. (there is no profit. it's supposed to be fun, right?)
One of my friends got a Pimoroni InkyFrame and was trying to figure out what to do with it. Ended up learning a substantial amount about how dithering works to convert images into the 7 colors the eInk display can produce. It just sits there playing the original Shrek at 1 minute per frame over and over again XD.
When he messed up the color conversion "Green Farquaad" was a recurring meme in our group chat.
I just have to add that this is a fucking brilliant plan. The number of useful things you will learn doing this is very high.
I can recommend a 'Hacker Boxes'[1] subscription. It's $44/month currently, every month you'll get all the parts to build some gizmo or project and a full list of instructions. The prerequisites are that you know how to solder and have a soldering iron, and have a computer you can run the Arduino IDE on (even a Raspberry Pi can do that these days).
If you don't know how to solder the Hacker Boxes folks have a soldering workshop kit that includes an iron[2], but many maker spaces will do soldering clinics. Soldering irons are available as cheap[3] and more expensive[4] (and ludicrous[5]). The Arduino IDE runs on pretty much anything (Linux, MacOS, Windows).
[1] https://hackerboxes.com/
[2] Soldering Workshop --- https://hackerboxes.com/collections/subscriptions/products/s...
[3] $13 iron from Amazon --- https://www.amazon.com/dp/B09DY7CCW5
[4] ~$150 soldering station --- https://www.amazon.com/dp/B077JDGY1J?th=1
[5] $1000+ Metcal station --- https://www.qsource.com/itemdetail/?itemCode=MX-5210-M020
get an ESP32, costs about $1-3
you can program it with the USB and the Arduino IDE
most dev boards (that means the MCU is put onto a PCB and you can do stuff with its pins) already have a LED on it so you can blink that without any soldering
they also usually have two tiny buttons one of which doesn't do anything/much and you can use those as input
ESP32 also has built in Wifi and you can make it host a supertiny webserver, or even be its own AP. It also has Bluetooth but I haven't tried that yet.
You can do all these things by asking ChatGPT for the code and instructions :-)
It can do a lot more than this though, but it might inspire you to try other things.
Oh one more very cool thing if you're just getting started is that the ESP32 has 10 pins which are "capacitive touch" sensors and attach a wire to that pin and if you touch the wire, your program gets a signal. This works very well and makes that you can do interactive stuff without even having to solder buttons on anything.
I have plenty of ideas, I'm just super lazy!
I'd like to hook up a rain sensor to a skylight to close it when it rains (needs a little motor, too), and then also hook it up to weather forecasts.
I currently have to switch on my TV, surround set and a laptop, and then push multiple buttons to switch to/from a firestick. I'd like to automate that, so I can just switch it on/off and switch the source easily. Also if the system is in an unknown state (tv on, but using the incorrect HDMI input and the surround set if switched off, etc.), which is what the naive solution using a "fingerbot" and a IR blaster hooked up to godawful tuya stuff doesn't do.
Build a GPS-synchronized flip clock.
Add remote control door opening without destroying my flat's intercom system.
Mostly kinda boring home automation stuff, but would be worth it for tinkering.
> Add remote control door opening without destroying my flat's intercom system.
Oh hey, I made that[0] at a previous apartment! It sat on my LAN and I'd VPN in if I was out of wifi range.
I struggle to find time/motivation for stuff like that these days. I was contracting back then and had downtime between jobs.
[0] https://github.com/jeremy21212121/doorman-building-arduino
As someone who is only mildly bullish about AI, my hope is that such ultra custom HA will be more common, and no longer limited fo the 0.1% and software engineers.
I can't get my head around it sometimes. I know most end up doing duties that a PIC-chip could do but the fact you can get a WiFi enabled microcontroller few a few bucks blows my mind.
The IO co-processing on the Pico is so powerful, I hope they expand on this.
It's also not really clear that using some of the more powerful chips for simple things is really a "waste" in any reasonable sense of the word. The packaging of a PIC/CH32 is probably the majority of its cost and environmental "footprint".
An RP2040 is not much more physical material.
An ESP8266/ESP32 is rather bit more material, but still not egregious.
Right? Especially when I remember paying $20 each for an 8-bit microcontroller with less than 1k EPROM.
Don't modern NICs do a lot of the same, too?
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.
The fancy Mellanox NVIDIA Connect-X cards have kTLS support which offloads encryption to the NIC, Netflix has blogged about how they use it to send 100 Gbps encrypted traffic of a single box (Their OpenConnect infrastructure is really cool).
Old is new again :)
Great hack from very talented hacker. Steve Markgraf is the author of High Speed Data Acquisition over HDMI https://github.com/steve-m/hsdaoh Capturing raw data using super cheap USB3 HDMI Video Capture dongles. Up to 175MB/s with Pico2 as the sender https://github.com/steve-m/hsdaoh-rp2350
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.
> 1Gbit uses easily reachable 125MHz clock
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?
Hey, this is fantastic! Thanks!
Something related to this that is really cool is directly reading from PDM microphones using PIO: https://github.com/ArmDeveloperEcosystem/microphone-library-.... This shouldn't be called bit-banging though if it's using PIO.
I think it still counts as bit-banging -- the PIO just lets you bit-bang faster and in a more limited way.
This is only talking about TX, presumably it can't receive? That'd be the hard part...
Right, it's TX-only. The article says so explicitly halfway through:
"As before, this is a transmit-only proof of concept"
I didn't notice that on my first reading.
> "As before, this is a transmit-only proof of concept"
I didn't spot that at all. Oops/Thanks!
And here I was thinking I could use a Pico as a USB ethernet dongle in a pinch /s
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.
Would this have been possible without PIO?
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.
>"bit-banging" typically means using the CPU
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.
It's a programmable hardware peripheral runs compiled software to toggle pins in a way that is entirely defined by that software.
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.
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.
Yeah but like FPGA fabric can also be programmed (sometimes by actual software like on Zynq or Stratix SoCs), would you call those bit banging too?
I feel most people would unless you use some Hard IP for the interface. Like you don't bit-bang PCIe when you feed a wide AXI stream at a few MHz into the PCIe block where it get's serialized and put onto the lanes at the signalling rate (multiple Gigahertz, depending on generation).
I don't have any hands-on experience with FPGAs. I only know about as much about FPGAs as I do about red herring.
>On a Pico? No
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.
They really are pretty awesome little ICs. Thanks for the interesting link!
It's why I call the Pico a "headless Amiga"—the PIOs are basically Coppers but for general I/O instead of tied to a display.
I just wish the toolchain weren't so janky...
There's an independent reimplementation of the PIO assembler here: https://crates.io/crates/pio -- I haven't tried it so don't know how good.
Intriguing, but I'm referring to the toolchain as a whole. Everything is done with CMake mumbo jumbo that is a pain to set up. For a computer this small and simple there should be a straightforward "compile .c to .o, link .o to flashable binary, flash binary" that any user can type in at the shell or put into a Makefile.
I think XMOS can do it (the ones without the GEMAC) but I'm not exactly sure how much hardware assistance they have.
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.
How does PIO compare to Cypress PSoC?
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).
That sounds similar
A coprocessor sounds similar to an FPGA?
stick with psoc for anything professional
> Raspberry Pi Pico Bit-Bangs 100 Mbit/S Ethernet
Per Siemens? I'd prefer Ohm!
This is not exactly comparable but to put things in perspective, the original RPi (rev B) could serve at ~6 MB/s over SSH.
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?
I think it's the signal they're "converting" to ethernet. That'd be the "digitizing some WBFM IF signal with the internal ADC" part. What I don't know is what's in the signal :P
and must not be connected to PoE-enabled hardware.
I assume passive PoE; or does it also happen to look like a real PoE PD and trick the PSE into turning on?
Pico's reaction as it sees 48V signals on its 3.3V pins: perfectly cut scream that transitions into an explosion
I wish something like Pi Pico existed but with 1GHz clock, DDR3 memory interface and PCIe and few dozens of GPIO.
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.
Xilinx Zync have PL for FPGA programmable logic, and PS with a few different ARM cores. They aren't as cheap as a Pi Pico though.
People have bit-banged out analog NTSC and PAL video signals before.
I mean, that’s basically what a DAC is, half the time
Just usually not driven by timed code by a program running on a CPU. That's when it becomes bit banging.
But how much juice is left to do useful stuff?
Or you could just buy an ESP32 board at about the same price, which already has an integrated Ethernet MAC (besides WiFi).
But where would be the fun in that?
You'd still need a Ethernet phy with the esp32 this does that too.
That's the best part though.
With an external PHY you can use single pair ethernet, which is much more suitable for use in embedded devices. Single pair ethernet directly competes against I2C and CAN, because you only need 2 wires for full duplex 100mbit/1000mbit connectivity.
Single pair ethernet also has the massive advantage that it isn't restricted to the garbage RJ45 plugs, which are basically a nightmare in embedded devices.
To make a compliant ethernet signal from this you would need at least some sort of line driver/receiver as well.
[flagged]
Not quite the same but I was looking at PowerBook G4 specs last night. Apple was doing gigabit ethernet in a mid-priced laptop ($2200 in 2001 dollars) 25 years ago. Meanwhile I'm pretty sure I have some 10baseT gear kicking around.
It’s not the same thing! Pico is a microcontroller, it’s also not a native ethernet implementation.
That would have had a dedicated chip doing the work.
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.
Here you go, I2S output:
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.
Maybe totally my fault for being dumb, but the ESP32 has an I2S peripheral and after days combing through docs and web searches I never actually got it working, mostly because it seems to have been barely documented and its usage was by twiddling magic registers etc. I’d say personally some nice example PIO code that I can actually read through, understand, and modify for my needs is actually better…
> I’d say personally some nice example PIO code that I can actually read through, understand, and modify for my needs is actually better…
I agree and that's why its disappointing RP still provides half-baked examples instead of real working implementations of the common peripherals other manufacturers are supporting.
https://github.com/malacalypse/rp2040_i2s_example
It's almost as if different equipment can serve different purposes...