* 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.
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)
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.
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.
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.
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.
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'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.
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.
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?)
When he messed up the color conversion "Green Farquaad" was a recurring meme in our group chat.
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).
[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
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.
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
The IO co-processing on the Pico is so powerful, I hope they expand on this.
An RP2040 is not much more physical material.
An ESP8266/ESP32 is rather bit more material, but still not egregious.
Old is new again :)
"As before, this is a transmit-only proof of concept"
I didn't notice that on my first reading.
I didn't spot that at all. Oops/Thanks!
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.
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?
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 just wish the toolchain weren't so janky...
Per Siemens? I'd prefer Ohm!
I assume passive PoE; or does it also happen to look like a real PoE PD and trick the PSE into turning on?
But where would be the fun in that?
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.
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.
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.