A Look At The Interesting RP2040 Peripheral, Those PIOs

The Raspberry Pi Pico is the latest product in the Raspberry Pi range, and it marks a departure from their previous small Linux-capable boards. The little microcontroller board will surely do well in the Pi Foundation’s core markets, but its RP2040 chip must have something special as a commercial component to avoid being simply another take on an ARM microcontroller that happens to be a bit more expensive and from an unproven manufacturer in the world of chips. Perhaps that special something comes in its on-board Programable IO perhipherals, or PIOs. [CNX Software] have taken an in-depth look at them, which makes for interesting reading.

The PIOs are a set of state machines that have their own simple assembly language to execute simple repetitive I/O tasks without requiring the attention of the main processor core. How they can be configured is up to the imagination of the programmer, but examples suggested are extra I2C or SPI buses, or video interfaces. We expect the hacker community to push them to extremes with unexpected applications, much as has happened with the ESP32’s I2S peripheral. The article introduces the assembly language, then gives us simple examples in assembler, C/C++, and Python. If you have a Raspberry Pi Pico then you’ll surely be wanting to have a play with the PIOs, and we look forward to seeing what you come up with.

You can read Hackaday’s review of the Pico here.


41 thoughts on “A Look At The Interesting RP2040 Peripheral, Those PIOs

  1. I wouldn’t say “simple assembly language”. It’s a small set, but the operands make them quite versatile and complex to use. Destination, source, buitlt in extended delays, simultaneous IO pin actions (side-set) in addition to the normal IN OUT commands, make them fairly complicated to follow what will happen. But I’m no assembler nerd so I guess my expertise shows.

    1. They look a bit like microcode, with multiple actions going on at the same time, and you need to understand the hardware itself (data paths, timing, and such) a bit more than with a conventional instruction set.

  2. 1. power. RP 2040 is still not good project.
    this is still not autonominous, mobility device.
    connect Lipo on board, or solar panel etc.
    1a. more function for stepping down cpu
    2. in my opinion small fpga is still good idea for this device. (like qomu, fomu)
    qemu emulation

    Meybe little more ram. many projects need 400-512KiB ram but in this I’m not expert

    we have 21 century and still all project are wired to power ;( i need emergency, long working device, apocalipse zombies etc. device

    1. “i need emergency, long working device”

      Such projects should be engineered from the ground up for ultra-low power. This means you are looking in the wrong place entirely if you are looking at a generic project board.

      1. I think erger got a point as the need for a versatile, cheap and ubiquitous (ultra) low power device that can be used in variety of project (ranging from telecomunication to sensors data aggregation etc) is real and not catered yet IMO….

        1. His point is that this product which is designed for a totally different purpose doesn’t do what he wants and you think he’s right to complain because there is a need for the product he wants (which this one does not pretend to be).

          Okay then. The Honda Civic is totally unable to tow a full-sized cargo container with 50 tons of cargo. What a crappy vehicle, I don’t even know why they bother putting it on the market.

    2. Approaching the problem from wrong end. If you don’t have good constant power, you can’t be wasting what you have to keep a micro running and mostly doing nothing. Charge, power up compute unit and quickly do what you need, kill power. Rinse and repeat and nauseum. You can run whatever powerful micro you need that way forever.

    1. I smell audiophoolery
      How would jitter be important in any shape or form in a clocked interface like I2S? You could maybe argue (after listening to brown note for too long) S/PDIF needs low jitter as its self clocked, but then again is S/PDIF jitter tolerance lower than that of DVI (PIOs can bitbang DVI at 720p)?

      1. The I2S interface itself isn’t sensitive to jitter, but the I2S clocks are typically used to clock the delta sigma modulator in the ADC or DAC. They are sensitive to jitter, and some ADC or DAC devices include a PLL to reduce that jitter. (They also can include a PLL to remove the need to have MCLK (typically 256 x Fs, etc.) run across the PCB, instead deriving that frequency on-die from one of the lower frequency clocks.)

    2. Jitters is all about clock cycle to cycle stability. i.e. the clock that is driving the data bits on a protocol that have *separate* clock + data format. The data bits can have jitter all they want as long as they are within timing specs.

      You want the cleanest clock generator circuits with a clean power supply, good quality oscillator that have low jitter spec, good PLL, good clean PCB layout, solid power/ground planes, good decoupling, good signal integrity. etc.
      Everything is meaningless if you slap this on a breadbord with fly wires all over the place like a typical HaD duct tape project.

      How well this module performs? It might be best effort layout only as not everyone are trained to do these kind of things. There are peope that know how to make low jitter clock reference for good scopes, GPS, digital commnication etc.

      Without doing an actual cycle to cycle clock jitter measurement, one cannot answer that question. If you want know quality, use a external DAC that regenerate and have jitter filtering on this.

      1. Arduino doesn’t even have Arduino support, seriously. When you select which “Arduino” you are using it defines a preprocessor variable that causes the correct header file (a compatibility layer) to be included. That header file defines memory addresses and values as preprocessor variables. Therefore, if you use Arduino hardware that is newer than your software then it won’t function properly because it doesn’t have a compatibility layer.

  3. Could the Pico, with its PIO feature, be used to controll an old laptop display? Background: all other instructions for reusing laptop displays I’ve seen involve buying a custom controller board from aliexpress for the specific display model. I hope the Pico or something similar could evolve into a universal replacement for such boards, together with a community site that catalogs different display models and lets users upload Pico code for them.

    1. I haven’t looked at the Pico enough yet to say for sure if it could really do any of them. But I do know old laptop screens are not trivial to run, they don’t all use the same number of pins or signalling methods, so compatibility will be tricky, which is why you are buying the control board for that specific display..

      I’d suggest it probably could, if you know enough about how the screen does its signalling to tell the PIO how to drive one, but that isn’t based on anything beyond knowing such things are possible on other relatively cheap FPGA boards. Yet to find time to look at the Pico at all, though it sounds interesting, and being the Pi foundation you know without looking the documentation and support are going to be superb.

  4. I’m looking forward to driving those parallel tft panels with 16bit motorola 6800 bus. Should allow easy 60fps at 480×320 and 16bit color, perfect for not so small handheld console.

      1. You can also buy screen from waveshare or adafruit and take the screen from carrier board. That carrier board is typically SPI (16x slower for 16bit interface), but tape to screen is TYPICALLY full width 40pin interface. Just buy cheap socket, there’s nothing too hard in that interface.

        1. I have plenty of screens of that type, and it is ( much )cheaper to buy only the screen ( with touch panel ) than buy the adafruit/waveshare ones and discard the boards.

          The point is to have enough pins to drive the panel, and also the necessary speed.

  5. That tiny instruction memory looks really small. I’m imagining trying to output HDMI with it and having to buffer entire frames at 80% efficiency with software preprocessing because I really doubt someone is going to encode bytes to TMDS and output in 32 instructions.

    1. You’re thinking of it as a generic co-processor you need to put the whole output program into, when it’s actually a configurable state machine fed by a fifo. You can stream state transitions and whole executable instructions to it, not just data.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.