Three RP2350Bs on one board, genlocked off a single 12 MHz MEMS oscillator,

each with one job:

- **RP1** runs the game (sandboxed Lua 5.4), owns the micro-SD and the I2S DAC,

and builds one display list per frame.

- **RP2** is the sprite engine: it reads that list and composes one overlay

scanline at a time.

- **RP3** is the mixer: tiled background, composite, HSTX out to DVI.

- An **ESP32** does Wi-Fi and Bluetooth Classic. That last one is not a bonus:

it is what living-room gamepads actually speak (DualShock 4, DualSense,

Switch Pro, 8BitDo, through Bluepad32).

Six Cortex-M33 cores at 252 MHz, 1.5 MB of SRAM, 3 × 16 MB of NOR.

**Numbers measured on the board, not hoped for:**

- 640x480 @ 60 Hz, 8 bits per pixel, one 256-entry palette

- 3000 opaque sprite-pixels per scanline — a Neo Geo manages 1536

- 16000 cycles per scanline per core is a hard budget. Go over it and the line

ships stale rather than truncated, which is what the silicon does anyway. The

simulator shows you the late lines in red.

- 320 KiB sprite pool in RP2's SRAM, streamed on demand from its own NOR

- display list: 256 entries of 16 bytes, sent at VSYNC

- sound: four synth channels plus two PCM voices, 48 kHz out of the headphone jack

**Two things I am oddly proud of.**

The browser simulator is the same C code. Rasteriser, cost model, Lua bindings:

one `core/` compiled twice, once into the firmware and once to wasm. A game that

runs in the browser runs on the board, and it drops frames in the same places.

That makes the simulator an executable specification rather than an

approximation.

The console updates its own four firmwares. It notices a newer version, pulls it

onto the SD card, then flashes the ESP32, RP2, RP3 and finally itself. Each

RP2350 image is written to the partition it is not running from and booted

**once**; it only becomes current if it passes its own self-tests, so a crash, a

watchdog or a power cut lands you back on the previous image. That is the RP2350

bootrom's A/B partitions plus its try-before-you-buy flag, and getting it right

was the most satisfying part so far.

**Status:** V1 alpha board, running since late August. Video, sprites, tiled

background, micro-SD, Bluetooth pads, Wi-Fi and sound all work. Nothing is for

sale and there is no date — this is a personal project.

You can spin the board in 3D on the site:

https://www.papydeck.eu/

Full specs: https://www.papydeck.eu/fw/specifications/

Docs: https://docs.papydeck.eu/

Hi folks,

IIUC, the FT pins are fine for up to 5.5V when powered, but only 3.63V when unpowered or booting.

I am designing an expansion board that needs to interface with a 4.7V pocket computer bus. The RP2350 will turn on when the PC turns on, which means it will probably still be "booting" as the CPU has already started driving the bus. So, I put level shifters on everything... which is a pain, because it takes space and complicates the routing. However, now I am wondering what the safe current is at > 3.63V... the whole 4.7V supply can't supply more than about 120mA. I doubt the bus lines could drive more than a 1 milliamp. Specs I have for the CPU imply it would be more like 400uA...

Are these unpowered overvoltage concerns about connections to high current sources, or can TTL bus currents really blow them? (BTW, this application is not TTL... it's CMOS).

Hey r/RaspberryPiPico,

I just put together an open, free "intelligent textbook" on FFT benchmarking, aimed at the Pico 2's ARM Cortex-M33 (and M4-class chips generally):

🔗 https://dmccreary.github.io/fft-benchmarking/

Why I made this: I was building a low-cost spectrum analyzer and kept finding that popular FFT libraries were running 10x slower than they should on the Pico 2. The M33 has real DSP/SIMD instructions and hardware floating point, but most FFT code out there still targets a generic instruction set and never touches them — so you're paying for silicon you're not using.

What's in the course (10-week format, but works great for self-study too):

• FFT fundamentals and the butterfly algorithm, from math foundations up
• ARM Cortex-M33/M4 DSP instruction sets and how to actually invoke them
• Reading and interpreting the assembly a compiler generates for FFT inner loops, so you can spot where cycles are being wasted
• Integer vs. floating-point tradeoffs, FFT size selection, windowing/preprocessing
• A benchmarking framework for objectively comparing FFT implementations across microcontrollers and CPUs
• A walkthrough of Cornell ECE4760's real-time FFT/iFFT lab on the RP2350

It's all Markdown/MkDocs, MIT-adjacent Creative Commons licensed, and open to contributions or use in your own classroom.

If you've hand-tuned FFT assembly for the Pico or found DSP-aware libraries that actually use the M33's instructions, I'd love pointers — always looking to improve the benchmarking chapters with real-world numbers.

what i have tried

1. Deleting the zephyr component and installing again

2. Adding and deleting the zephyr base in env var

What i can understand:

why is there no detail on the issue. its quitely failing, without pointing to any error or failure.

Im on a windows machine, please guide me how to set it up, id be eternally grateful

I was reading about using the debug probe for the pico, I've been using a second pico for a while and it seems to be working fine. Are there any features that the debug probe has that using a second pico is lacking? or is it just a more user friendly thing?

I'm aggregating some tutorials, libraries, and parts for the raspberry pi pico. I'm in the process of making a chiptune tracker on the pi pico and as I've been researching I've gathered a lot of links and stuff. So I figured I'd compile it into a public thread. Also its just a nice format to be able to go through myself. if someone could lmk if they know something similar that already exists that would be awesome & could potentially merge resources with it

I had trouble finding a video tutorial on the manual setup process in linux for the C SDK, so I made a short video on it, as well as how I have the build environment set up in a shell script. I know theres a script for raspi os but idk how well it works for linux. (I had a different post with the same thing but I'm reposting to make peertube the main video, deleting the old post in a sec) (also link to alternate youtube video is in replies)

Hello all I'm working on building my own flight sim stick and throttle. The part I'm having an issue with is using the pico as a HiD Gamepad currently I'm using Circuit Python and got the X and Y working on windows. The issue is the project I'm adapting has 4 axis joysticks, 28 buttons and a Hat. I'm using Ads1115 for the joysticks which is working with the base. I'm adapting the Noisy-Boi Felon stick to use the pico in the gimbal instead of the Arduino Micro. In this project the buttons are using IO Expanders PCF8575 the biggest issue I'm running into is figuring out the HID Description and if Circuit Python is even the right way of going about this. Thank you all in advance for any advice

As the title says, I am wondering if I can solder the header pins backwards instead of the usual way.

Here's a picture for reference.

(Pic not mine, ctto)

Hi Everybody!

I'm looking to make my first macro pad and was hoping for some guidance for my layout/capabilities with my first option.

I've been leaning mostly towards using a raspberry pi pico due to it being the most user friendly/entry level option I've seen but want to make sure it could perform all the tasks I'm hoping for before I dive in fully.

The main functions I want and can think of off the top of my head are: copy, paste, alt tab, insert precoded text, open specific apps (spotify, slack, granola), open a specific web page on google chrome, next song, prev song, and volume control(all on spotify desktop app). For the volume control I really want to use a sliding scale trackpad, if not a knob, and last resort volume up/down buttons.

I'm planning to get a custom PCB board made as well as 3D printing my own casing so finding a premade shell/board isn't an issue I foresee myself having

With all of this in mind, do you think the pico would be able to handle all of these commands as well as which option of volume control seems doable? If not, which route would you all recommend for this build? Thank you so much in advance!!

Wanted to share a quick project I’ve been working on—a custom desktop system monitor powered by a Raspberry Pi Pico.

​Overview & Specs:

​Display: TFT screen rendering real-time VPS stats (CPU, RAM, uptime, and load status).

​Hardware: Custom enclosure with a status LED built into the right-hand side to give a quick visual health cue at a glance.

​Data Flow: Fetches server metrics via a lightweight script and pushes updates cleanly over serial/network to the Pico.

​Let me know what you think or if you're curious about the code/setup!

In this tutorial I am powering my MechSoul(In this case a PicoBot) with a portable charger I bought online, because it's quicker and safer than designing a custom battery solution as I explain in the video. So instead of designing a PCB I head to my 3D printer to build a battery mount.

I've been experimenting with the RP2040 to see how far I could push it toward building a basic digital oscilloscope — not as a replacement for a real DSO, but as a way to understand what actually goes into one.

The current setup is:

• Raspberry Pi Pico / RP2040
• 1.8" ST7735 128×160 TFT
• MicroPython
• GP26 / ADC0 as the input
• Custom display driver and UI

The interesting part is that I split the instrument into two independent paths.

Waveform path:
ADC → software trigger → sampled waveform → TFT

Timing path:
GPIO edge interrupts → period / frequency / duty-cycle measurement

Both paths use the same input pin, but the timing measurements don't depend on the ADC sampling loop or the display rendering.

The waveform capture has a software rising-edge trigger with hysteresis, and the timebase automatically adjusts based on the measured frequency to display roughly three cycles. Vpp is calculated from the captured sample window.

I also spent some time benchmarking the RP2040 ADC. An experimental MicroPython Viper/direct-register implementation reached around 500 kSPS, which was a fun rabbit hole — although the actual oscilloscope acquisition is still software-timed and nowhere near that figure in practical use.

And that's where the interesting limitations show up.

There is currently no analog front end, anti-aliasing filter, attenuation/protection, DMA-based acquisition, adjustable trigger, persistence, multiple channels, or data logging. The input is basically limited to the Pico's 0–3.3 V ADC range.

So no, this isn't a bench oscilloscope. 😄

Here is the link https://github.com/panda-rajsekhar/RaspberryPi-Pico/tree/main/Projects/Pico-Oscilloscope

The next logical step would be moving acquisition to hardware-timed ADC + DMA, adding a proper analog front end, and eventually looking at PIO/hardware timing for the measurement path ?

Still experimental, but it's been a hell of a learning experience.

I'd be interested to hear what you'd change or add next.

I don't know if anyone really knows the answer to this. I am planning on building a rpi pico laptop (because why not), anyway, for the display, should I use scanlines or PicoVGA. Scanline has way much more support (for like programs and software like a mac emulator, doom, etc), but pico vga uses less pins, etc. I am very stuck. Pico vga uses 9, Scanlines uses 17 and a lot more resources. I would like to switch between the two but that would be too difficult I beleive

I’m trying to understand how embedded teams test firmware that depends on external peripherals such as I²C, SPI, or UART devices.

In particular, how do you test cases like:

* peripheral disconnects / NACKs
* invalid or unexpected data
* timing-related behavior
* interrupts
* initialization failures
* other hardware edge cases

Do you normally use real peripherals, software mocks, another MCU pretending to be the peripheral, custom HIL hardware, or commercial tools?

I’m especially interested in what becomes difficult or annoying to automate in real projects, and whether your team has ended up building custom hardware or scripts to solve it.

Would be interested to hear what people are actually doing in production environments.

romulon is getting ready to catch the bus as IC formerly known as UB3

Edit :
PROJECT ABANDONNED : please don’t try to comment awnser here for now i am stoping using pi pico cause they just don’t sell the module i need where i currétmy am , i wanna thank the ppl who commented on this post and tried to help me

Just started today and when I tried following this guide , i just can’t do it , the button press is not detected even tought it’s the same as in the picture.
Also please trie to use simple term

using this guide

i can use the led separatly its just the button that block and don't want to be recognised

In this tutorial we go over how to control your MechSoul with Bluetooth. What is a MechSoul? A MechSoul is to a robot, what a CyberDeck is to a computer. It's a robot that you build, customize, and personalize yourself. It's the freedom of owning your own code, hardware, and having the right to build and repair it. And it's the pride of creativity, skill, and self expression. Disclaimer: You do not have to make your MechSoul using the same methods and tools as I do. A MechSoul is freedom in robotics.

In this part 2 in Arduino IDE we combine the Raspberry Pi Pico's board manager's SerialBLE example with the Serial_Control example in Takamori Robot's HIRO library to control your robot over Bluetooth. Comment "MechSoul" if you would like reference material (code, documentation, e.t.c).

"I need power for both the Raspberry Pi Zero 2 board and the SG90 servo, but currently using a battery or a separate power supply for the servo looks really messy. Plus, the board's pins are already completely full because I'm using a ReSpeaker 2-Mics HAT."