r/raspberrypipico

I teach high school CAD classes, and we make soccer-playing robots. For controllers we use Picos and nRF24L01 wireless modules. This year we started tracking them with an overhead camera (camera module 2) and a Raspberry Pi 5 with OpenCV, and we send all the robot's coordinates and orientations to this board with those red, white, and yellow wires via UART.

The students can program their Pico to give their robot autonomous functions, like always stay between the ball and the goal, or go to the ball, or aim and shoot the ball. Whatever they want. Since there are four robot color combos (blue/pink, blue/green, yellow/pink, yellow/green) the students can put their Pico in the appropriate slot for their color assignment.

Anyway, it's been a ton of work and I'm really excited about my sockets. I wanted to use ZIF sockets, but they don't seem to be wide enough, so I took advantage of the edge castelations. I bent all those wires and 3D printed the bases. It turns out it's really hard to solder to spring steel. I should have bought those FlexiPins, but I didn't.

I bought a dsPico for my dsi, I downloaded everythinh successful, including an snes emulator. All I'm missing is Gbarunner3. For some reason it keeps saying the error, (can't open file!) can someone help me. It used to give me a completely white screen. After a crazy struggle I got it to say can't open file. I have a 128GB microsd card, which is a lot. I know. But it should work right?

​

I’m trying to connect a 1.3” 240x240 SPI TFT display labeled “CST7789” to a Raspberry Pi Pico 2 using MicroPython.

The display backlight turns on, but the screen itself never changes or displays anything.

What I’ve tested so far:

.Pico works correctly

.onboard LED test works

.SPI commands are being sent without errors

.reset and DC pins are toggling correctly

.I once saw a brief flicker on the display during testing

Current wiring:

SCL -> GP18

SDA -> GP19

RES -> GP20

DC -> GP21

VCC -> 3.3V

GND -> GND

BLK -> 3.3V

The module does NOT have a CS pin.

I’ve tried:

.swapping SCL/SDA

.lowering SPI baudrate massively

.multiple initialization sequences

.checking breadboard connections

Current test code:

from machine import Pin, SPI

import time

spi = SPI(

0,

baudrate=10000,

polarity=0,

phase=0,

sck=Pin(18),

mosi=Pin(19)

)

dc = Pin(21, Pin.OUT)

rst = Pin(20, Pin.OUT)

def cmd(c):

dc.value(0)

spi.write(bytearray([c]))

def data(d):

dc.value(1)

spi.write(bytearray([d]))

rst.value(1)

time.sleep_ms(100)

rst.value(0)

time.sleep_ms(100)

rst.value(1)

time.sleep_ms(200)

cmd(0x11)

time.sleep_ms(200)

cmd(0x29)

Does anyone know if:

this display needs a special init sequence,

different SPI mode,

or if the module itself might be defective?

Long-time lurker, first time posting a project here.

Github : https://github.com/colonelblacc/Dynamic-Braille

**DynaBraille** is a reading desk for blind students. The embedded side is what I want to share — the Raspberry Pi handles all the AI, and the Arduino is purely a real-time servo driver receiving character packets over UART.

---

**The Braille Cell**

6 SG90 micro servos in a 2×3 grid inside a custom 3D-printed PLA housing. Each servo arm has a pin attached — rotating it raises or lowers the pin through the top plate to form a Braille dot. Any Grade-1 Braille character = a specific 6-bit servo configuration.

The Pi sends packets over serial UART at 9600 baud:

```

BRAILLE:100100\n

^^^^^^

dots 1–6 (1 = raised, 0 = lowered)

Dot layout:

1 4

2 5

3 6

```

The Arduino sketch parses the packet, maps each bit to a servo, and positions them. 400ms settle time between characters to let the servo arms fully actuate before the user touches the dots.

---

**Touch Sensor for Word Advance**

A capacitive touch sensor is mounted on the **side** of the housing. The student's fingers rest on the Braille dots; they tap the side sensor with their thumb to advance to the next word. The Arduino detects the tap and sends a `NEXT` signal back to the Pi over the same UART line. Hands never leave the device during reading.

---

**The Pi Side (brief)**

- Pi Camera 3 → perspective warp → CLAHE enhance

- PaddleOCR (English) with confidence fallback to Tesseract (Malayalam)

- Gemma 2B via Ollama for OCR cleanup — runs fully on-device

- pyttsx3 TTS + Vosk offline ASR

- Gemini 1.5 Flash optional (explain/summarize/describe diagrams)

Full offline mode: `python main.py --no-gemini`

Happy to discuss the servo timing, UART protocol design, or the touch sensor debounce logic.

Hi everyone, I wanted to share my latest project the Pico 3x as I’m calling it, I’ve been working on this for a while and I’m a beginner when it comes to coding so this is a massive thing to actually get working. It’s currently running a pico 2 but I have all the parts to make another one with a pico 2 w (which is the original plan), it’s got a Pimoroni breakout garden style header, probe headers, an IR transmitter and a grove port for expansion. So far I’ve had help making a couple of games from tutorials, and a couple useful apps but it’s still very much in the development stage I terms of software. I designed the PCB myself and I will be uploading all the files and parts used to my GitHub in the next week or so. If anyone has ideas on features I could improve it with/‘app’ ideas that would be amazing. I’m using a main.py to run the screen and load different files on the pico and a button.py to handle inputs then I just add a new file to it for other ‘apps’. (I have removed the plugs on the amigo pro and soldered the battery directly to save space now)

I wanted a dedicated macro and audio control pad, but instead of buying one, I decided to build my own from the ground up – including custom software and firmware. The name is still a placeholder, but I’m super happy with how it turned out!

The Hardware:

• MCU: Raspberry Pi Pico
• Keys: 8x Clicky Blue Switches from Amazon
• Dials: 4x EC11 Rotary Encoders
• Display: 128x64 Monochrome OLED panel
• RGB: SEZO WS2812B ECO LED Strip at the bottom
• Bonus Feature: Added a vibration motor for actual haptic feedback when interacting with the deck!

The Software Stack:

• Firmware: Written entirely in Rust.
• Companion App/Middleware: Built with Tauri.
• It features a full GUI configurator, a manual bootloader, firmware updating, global LED effects, and per-app audio routing.

What do you guys think? Any suggestions for a final name or software features I should add?

Circuit here: https://freeimage.host/i/BDHfHzJ

This is my first audio project. I have an SD breakout reading 128kbps .mp3 files on I2S through a MAX98357 amplifier outputting to an 8Ω 3W speaker. Everything is working great, but the audio has a kind of raspy crackle/warble to it. On PC, the audio files are very clean. I've upped the clock speed on the pico to 133MHz wondering if perhaps things were just getting bogged down at 125 but that had no affect. What should I try to clean this up a bit?

Thank you

I’ve been working on a custom dual H-bridge brushed DC motor driver designed to replace those generic off-the-shelf motor modules for complex mobile robot platforms and robotic arms. I wanted a small all-in-one solution for robotics projects!

It's built around the Raspberry Pi RP2350 (Pico 2) and the Texas Instruments DRV8412.

Quick specs:

1. Runs two brushed DC motors at up to 40 V (3A continuous, 6A peak per motor)
2. Single wide voltage range power supply 4-40V
3. Per bridge current sensing - ACS722
4. Full ASCII + binary command API over USB, UART, and I²C
5. 4-layer 50x60mm PCB with a 3-stage clean logic power topology
6. Closed-loop control (position/speed PIDs) at a 4 ms control period
7. GUI for PID tuning

If you want to check it out, I did a full video on it, and it is also on GitHub.

Video: https://www.youtube.com/watch?v=DQ6VGJUASJw
Github: https://github.com/MilosRasic98/OpenDualMotorDriver 

Nothing better to do on a rainy day...

https://youtu.be/t2OhNIj8sUQ

This is a demonstration of a Rust server framework that uses flatbuffers for messaging. The framework's internals check for proper message routing at compile time.

In this demo, 200 message types are handled. The core message is a flatbuffer table with a union encompassing 200 different flatbuffer table types. The client generates random messages with random data and sends them to the server. The framework guarantees that each union is handled separately.  The response message mirrors the request message, with the order of elements reversed and sent back to the client, so the client can compare the fields that were sent as proof of work.

The screen on the left shows the demo running on a Mac Studio under macOS, and the screen on the right shows the same flatbuffer schema running under an RTOS (Embassy) on a Raspberry Pi Pico 2 W over WiFi.

I’m looking for organizations that would find this useful, people who might assist with further development, and especially people who could assist with marketing.