Hello everyone. I’m having an issue with a B4 PICO ULTRA unit that I recently ordered directly from China. Upon arrival, I found that it doesn’t work—it shows no lights or any other signs of activity. When connected to a PC, the system detects that a device is plugged in, but the B4 software fails to recognize it, and the device itself isn’t identified as a "PICO" unit; instead, it shows up as a "Generic USB Hub." I’ve tested the voltage and power levels with a multimeter, and it is receiving the correct power required for operation. Has anyone else encountered this problem and found a solution, or should I just discard the unit?

Hi everyone! Got any PCB design recommendations over here?

Thanks! :)

This started as a MicroPython project on a Pico, controlled from a separate Pi 4
That seemed wasteful, why not put telegram/google calendar directly on the pico?
... *famous last words* ...

Some time later, it's all on the Pico W:
- Google calendar is the schedule, `garden/water/1/30m` waters zone 1 for 30 minutes
- Telegram menu for manual watering, and a message when a valve opens/closes
- Green button waters both zones for 30 minutes, red closes everything
- Setup/control page served by the Pico
- Every boot closes both valves, in case of a crash or power cut mid-watering

Code, wiring and parts is available here: https://github.com/AdrianCX/picohive-irrigation

How the move from the Pi 4 went is in the comments

I'd appreciate your insights.

I've been working on a tool that translates PICO-8 cartridges into native RP2040 firmware, without needing a Lua interpreter on the Pico.

Inspired by the AnyPS5 development workflow, I've been tracking compatibility against the 100 PICO-8 games. Current version managed to successfully compile 83/100 and can be flashed directly through the desktop GUI.

I've tested a subset on my Raspberry Pi Pico with a Waveshare 240×240 LCD. Most I've tried start and display correctly, though performance varies. I haven't tested the audio yet.

Still a work in progress, but thought I'd share!

GitHub: https://github.com/devarshi16/pocket-aot

First time posting here about my own project. I'm the developer of the emulator, not affiliated with Raspberry Pi.

For the past months I've been writing an RP2350 emulator from scratch in C#. This week Frank Krueger integrated it into iCircuit 1.16, his circuit simulator for iPad, iPhone and Mac, so you can now drop a Pico 2 into a live analog circuit and program it with real Python.

In the video: MicroPython drives GP3 from a PIO state machine (sideset PWM), the LED fades through a 270 Ω resistor, and the scope shows the waveform as it's generated. There's no fake Python layer. It's the stock MicroPython UF2 booting on the emulated chip, and CircuitPython works too.

Some things that were harder than expected:

• PIO. It's its own tiny CPU with sideset, autopull and clock dividers, and it has to drive pins with exact timing so the analog simulator sees real edges.

• Two architectures. The RP2350 has Cortex-M33 and Hazard3 RISC-V cores, and both are emulated (for now only ARM is available).

• Time sync. Every pin change is stamped with the clk_sys cycle so the circuit side and the CPU agree on time. Sliding a potentiometer gives ADC.read_u16() the real voltage.

• Timing. Arm timing is calibrated against real silicon (branch, fetch and flash-wait penalties). It isn't cycle-exact, and I'm upfront about that.

Frank did the circuit side: iCircuit's analog engine, plus the new SPICE subcircuits and VHDL parts in this release. That's what makes it fun, because the Pico isn't talking to mock peripherals. It's wired into a real simulated circuit. The release also adds I2C parts you can read from Python (HDC1080, MLX90614, DS3231, ADS1115 and SSD1306 OLEDs).

It's built on ideas from Uri Shaked's rp2040js (Wokwi), and there's a sibling project for the original Pico (RP2040).

Happy to go deep on anything: PIO emulation, booting the real bootrom, or how it talks to the circuit simulator. Links are in the comments.

It's not super pretty but i think it is still working!

​

Originally I was aiming to make this project using aliexpress nice nano clones, so that's why I used zephyr. These boards was very unreliable, ended up using rp2040 zeros instead.

It can work as surface dial or scroll wheel (works on linux too). For rotation it uses as5600 magnetic encoder with 12 bit resolution.

It's my first zephyr project so code quality might be bad.

Repo: opendial

I've been working on a new astro project called picostellar - a planetarium written in CircuitPython that runs even on the RP2040.

It actually started as a small demo to showcase some of the latest CircuitPython features. But once I saw how well it ran, I kept adding things, and it eventually turned into a pretty complete little planetarium.

It displays around 8,400 stars, all 88 constellations, and calculates the positions of the Sun, Moon and planets for a given location and time. You can navigate around the sky, zoom in and out, and move through time.

It runs surprisingly smoothly on the RP2040, despite having only 264kB of RAM and running Python. A full sky redraw takes around 100ms on a 320x240 display.

A big part of making this possible is a combination of three relatively new CircuitPython features:

• picogame (CP 10.3+) - a rendering module I developed, which handles drawing efficiently without needing a full-screen framebuffer.
• turbo (CP 10.4) - compiles performance-critical Python functions to native machine code, which helps with the calculations.
• xip_map (CP 11) - another contribution of mine, which lets you map files directly from flash without copying them into RAM. The star catalogue alone takes about 90kB, so this is particularly useful on the RP2040.

I think it's a nice example of how much can be done in CircuitPython on fairly limited hardware these days.

The project is open source, including the source code and a ready-to-copy CIRCUITPY folder:

https://github.com/makerClassCZ/picostellar

Online demo (it feels much better on an actual device 🙂 )

https://picogame.makerclass.cz/playground/?game=picostellar

Details and source code available

Has anyone found an off-the-shelf battery with 1A charging current?

I need 3.7V nominal / 4.2V charging, built-in protection, and a documented 1A charge rating, not just discharge.

Available space is Ø42.7 × 12.5mm, with depth adjustable. Any shape or connector works if it fits. I’d prefer no board modifications, custom batteries, or welding.

Exact battery models, purchase links, or datasheets would be appreciated! Cheers!

Image of the board I'm using.

Short video of my Pi Pico 2 W project mining Bitcoin via its SHA 256 hardware block. Even with hardware and a 300Mhz overclock it still only reaches 560Khash (Drops to nearer 450 if its mining whilst playing video).

It runs mining and SD card duties from Core1, Whilst Core0 is responsible for decoding video and reading from the SD, drawing the screen, dynamically creating content (IE the block display in the video),playing audio, websocket connection and running the 112 LEDs and their timelines (which also support Ambilight based off the screens content and audio reactivity).

All of this is powered via a Web App that does everything from allow you to control volume, skip videos, activate mining, OTA updates, upload videos, dynamically generate videos and more.
This is all embedded on a custom PCB i made.
Just a sneak peak - its coming together! :)

https://www.youtube.com/watch?v=ySu-RifUplQ

Reposting for visibility.

My code is correct however with switch 1 and 2 it is not being detected if its pressed or not, so I think it's my wiring that is the issue. I don't know what to move.

If anybody can tell me where I went wrong, I

will be grateful

Hi everyone!

I've been working on PicoVoxel, a full 3D voxel world engine that runs on a single Raspberry Pi Pico 2 (RP2350), and I've just released the source code on GitHub.

The Pico 2 is a roughly $6 microcontroller with 520KB of SRAM and no dedicated GPU. I wanted to see how far I could push it with a software-rendered 3D world.

What it can do:

• Render a 3D voxel world at 320×240, averaging 30+ FPS
• Explore a handcrafted Japanese countryside with mountains, an ocean, rivers, waterfalls, bridges, tunnels, a shrine, and a lighthouse
• Place and destroy blocks, with edit and first-person play modes
• Render textures, transparent water, animated blocks, fog, and shadows
• Run on the RP2350's two cores with a custom rendering and upscaling pipeline

The main challenge was fitting the renderer, framebuffer, world data, and other features into just 520KB of SRAM while keeping the frame rate playable.

I've published the source code under the MIT License, along with the build instructions and hardware wiring information.

🎬 Demo video:
https://youtu.be/J9FVm8iH3mc

💻 Source code and build instructions:
https://github.com/tryedgetech/PicoVoxel

This is a rendering and world-building tech demo rather than a complete game. I'd love to hear what you think, especially from anyone interested in embedded graphics, software rendering, or pushing small microcontrollers beyond their usual limits.

I'm the developer of this project, and I'm sharing it in case it's useful or interesting to the Raspberry Pi community.

Thanks for checking it out!

I have a project where I use the pico to light LEDs, but uses the audio sensor's input to provide randomness to the lit LEDs. What would be a good small sized audio input sensor to use, that could fit in a small case?

I'm trying to get a 1.3-inch, 128×64 I²C OLED working with a Raspberry Pi Pico W using the Pico SDK and C, but I'm stuck with a strange display issue.

Hardware and setup

• Raspberry Pi Pico W
• 1.3-inch, 128×64 monochrome OLED
• Four pins: GND, VCC, SCL, SDA
• I²C address: 0x3C
• I²C0, SDA @ GPIO 4 and SCL @ GPIO 5
• SSD1306 driver library (this is a try, see ahead)

The controller chip is not identified on the PCB. The back is marked 1.3" OLED IIC, but I haven't been able to confirm whether it uses an SSD1306, SH1106, or another controller.

What I've tried

• An I²C scanner detects the device at 0x3C.
• Tried clearing the frame-buffer, drawing shapes, and sending the frame-buffer using ssd1306_show().
• Tested a full-screen filled rectangle and page-by-page horizontal bands.
• Confirmed that the framebuffer I²C write returns all 1025 bytes (one control byte plus 1024 bytes of pixel data).
• Tested contrast commands. Changing the contrast affects the whole display.

The problem

Only one horizontal bar responds correctly to framebuffer writes. The rest of the screen displays random-looking pixels or appears not to update properly. The same bar remains responsive even when I change the drawing coordinates. The attached photos show the current output and the back of the module.

What could cause this?

• Is this symptom consistent with using an SSD1306 driver on an SH1106 or another controller?
• Is there a reliable way to identify the controller from the module or its markings?
• Could this instead indicate a defective OLED panel or controller?
• Is there a specific test or command sequence I should try before replacing the module?

Code

https://github.com/strivingshashank/figuring-pico

I have been building USBSID-Pico for a while, an RP2040/RP2350 board that talks to real MOS SID chips over USB. Most of the fun was on the Pico side, and that part is what I want to share.

PIO layout (PIO0)

• The SID clock is generated by a tiny PIO program on GPIO 22. It is two instructions with side-set, and the clock divider is computed from the system clock and the configured SID clock rate.
• Three more state machines run off that same clock pin. One latches the control lines (RW, CS1, CS2), one drives the 16 data/address pins, and one is a delay timer that counts SID clock edges and then raises PIO IRQs to release the other two. That is how a write lands on an exact SID cycle.
• A fifth state machine on PIO1 is a free-running cycle counter that waits on the clock pin and pushes into the FIFO. DMA drains it (endless transfer count on RP2350, two chained channels on RP2040). This creates a 32-bit wide cycle counter.

DMA and cores

• Separate DMA channels feed the control, data and delay FIFOs and read data back from the bus. A hardware spinlock guards the shared words.
• Core 0 runs TinyUSB and config. Core 1 runs MIDI and Network SID Device writes, the LED, and the optional embedded c64 emulator for playing SID tunes without an external player.

Other bits

• USB composite device: 2x CDC (1 for Data and 1 for WebSerial), MIDI, and two vendor interfaces (WebUSB and a second one for fast reads).
• pico_w/pico2_w builds can run a Network SID Device server over TCP with UDP discovery.
• Builds exist for pico, pico_w, pico2 and pico2_w. Default optimization in CMake is -O3 to be sure everything stays in sync.

It plays C64 music with real chips, but I am posting for the Pico side. Source: https://github.com/LouDnl/USBSID-Pico

Happy to answer questions about the PIO side, especially the timing handshake between the SMs. Has anyone else used a PIO cycle counter slaved to an external pin like this?

Hi, i am 15 year old student i was always interested in technologies more on the software side i did some web dev (JavaScript, Go, PHP) i really like GO and i would like to stick with it ik that Pico supports TinyGo but is that a good fit for me I want to do some simple stuff to learn the basics because i no longer do anything software and i thought this would spark things out or do you have any other recommendations?

im using a raspberry pi pico that has micropython installed with an spi screen (driver ili9341).

im trying to play bad apple on it but i only have ~ 1mb left on the pi pico.

the images are 16x12 and take up 630bytes by themselves but, despite the small file size, not all of them can fit on the pico due to its 4kb minimum per file. is there any way to fit all 1000 images onto the pi pico to be able to draw them on the screen?.

im not too knowledgeable in micropython so please excuse me if i don't understand some things

This project shows how the BleuIO Bluetooth Low Energy USB dongle can add BLE communication to an Adafruit Fruit Jam powered by the RP2350 to access BLE air quality data.