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.
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.
Simple as in much simpler than a microprocessor assembly language.
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.
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
“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.
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….
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.
A Honda Civic can do that . :)
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.
I would be interest to know how the PIO peripherals in the RP2040 compair with PRUSS blocks in the am5538 (the SOC in te beaglebone black)?
Than was exactly my fist thought too. It’s a while back but IIRC the high level concept seems to be pretty similar.
Same here, I hope someone with the detailed knowledge can take a look.
or the UDBs in a Cypress PSoC… currently playing with one of these (PSoC5) and wondering if the RP2040 might be a better fit now… off to read stuff (again!)
The UDBs in a Cypress PSoC are better.
Just draw and connect your peripheral with components in the IDE.
More like a FPGA.
“Just draw and connect your peripheral with components in the IDE.” – IIRC, this is with a proprietary toolchain that’s Windows only?
Definitely not better.
I’m wondering how you would do I2S where the jitter requirements can be quite stringent, depending on what hardware you’re connecting to.
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)?
Wait, you’re saying it can “technically” output single lane DVI at up to 720p resolution? If yes, is that at 60Hz?
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.)
Exactly.
P.S. Any self-respecting audiophool wouldn’t be using digital anyways!
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.
I don’t see anything new yet, but what was already in those 6 PDF files released along with the announcement.
Very few of us can be arsed to read an entire 150 page+ data sheet. I just want Arduino support so I can use all of my libraries.
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.
Someone have to do the hard work reading them and implementing useful stuff and pt it on a silver platter for you to copy/paste.
There is no new magic technology added but the PIOs are a special feature among MCUs which is the entire point of the article.
Oh so it’s like a gimped cypress proc + all the negatives an 17$ shippinh
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.
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.
I think you run out of pins before the display runs out of inputs.
Depending on how old… TTL ok. Some TDMS limited by RAM for framebuffer, speed for data rate.
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.
Yeah, like those in cheap GPS units. That was my idea also, when I saw this new chip.
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.
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.
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.
One of the Raspberry foundation engineers already managed dual DVI (and HDMI is only marginally different): https://github.com/Wren6991/picodvi
“640×480 RGB565 image, 640x480p 60 Hz DVI mode” (overclocked at 252MHz)
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.
It looks like I was right about it needing a lot of assist from a CPU core though. I just overestimated the buffering needed by orders of magnitude.
Could you drive a string of, say 64 neopixels off each of those channels? It would be very useful to offload that timing task from the main processor.
Yes, you could drive 29 strings with just one state machine. One state machine can use all gpios if required, with 7 more remaining for other tasks.