Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • This is not exactly comparable but to put things in perspective, the original RPi (rev B) could serve at ~6 MB/s over SSH.
    by rldjbpin
  • 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?

    by userbinator
  • Pico's reaction as it sees 48V signals on its 3.3V pins: perfectly cut scream that transitions into an explosion
    by moffkalast
  • 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?
    by majke
  • 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
    by tecleandor
  • > Raspberry Pi Pico Bit-Bangs 100 Mbit/S Ethernet

    Per Siemens? I'd prefer Ohm!

    by junga
  • How does PIO compare to Cypress PSoC?
    by brcmthrowaway
  • stick with psoc for anything professional
    by sitzkrieg
  • 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).
    by deckar01
  • 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.

    by ryao
  • Unfortunately:

    > this is a transmit-only proof of concept.

    So a not-very-useful NIC for your Nintendo switch.

    by Doohickey-d
  • Would this have been possible without PIO?
    by unixfg
  • 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.
    by tylerflick
  • 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.

    by codebje
  • This is only talking about TX, presumably it can't receive? That'd be the hard part...
    by eqvinox
  • 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.

    by matthiasl
  • 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.
    by lukeinator42
  • I think it still counts as bit-banging -- the PIO just lets you bit-bang faster and in a more limited way.
    by wvenable
  • 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.

    by rasz
  • Hey, this is fantastic! Thanks!
    by kragen
  • > 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?

    by kees99
  • 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.

    by ChuckMcM
  • Don't modern NICs do a lot of the same, too?
    by nine_k
  • 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.

    by hunta2097
  • >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.

    by torben-friis
  • 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.
    by kragen
  • 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.

    by ggm
  • I understood some of these words
    by TZubiri
  • 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.
    by bri3d
  • 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...
    by kragen