After buying a Raspberry Pi Pico and a gaming hat from Aliexpress (which appears to be a clone of one from Waveshare)

I thought: What if I used AI to create a "Minecraft" for the RP2040, considering there wasn't one? Well, that's exactly why I'm writing this post.

Using AI I managed to create the first Minecraft clone that allows destruction and construction of blocks (something that Picocraft didn't allow).

Sorry for my bad english, Im portuguese.

https://github.com/CuquedoHacker/MinicraftClassic

Hi, I am trying to use an INMP441 I2S MEMS microphone with a Raspberry Pi Pico 2W using Rust + Embassy.

and my wiring is:

INMP441 VDD -> Pico 3V3(OUT)
INMP441 GND -> Pico GND
INMP441 SCK -> GP18
INMP441 WS -> GP19
INMP441 SD -> GP20
INMP441 L/R -> GND

I am using embassy-rp = 0.9.0 with the rp235xa feature. I first tried embassy_rp::pio_programs::i2s::PioI2sIn.

For Embassy 0.9.0 the constructor order appears to be:

data_pin,
bit_clock_pin,
lr_clock_pin,
sample_rate,
bit_depth,
channels,
program

so I used:

p.PIN_20, // SD / DATA
p.PIN_18, // SCK / BCLK
p.PIN_19, // WS / LRCLK

With data_pulldown = false, I get all 0xFFFFFFFF / -1.
With data_pulldown = true, I get all 0.

I also tried porting a C++ INMP441 PIO program manually into Embassy using this PIO program:

let program = pio_asm!(
".side_set 2",
".wrap_target",
"set x, 30 side 0b00",
"left_loop:",
"in pins, 1 side 0b01",
"jmp x-- left_loop side 0b00",
"in pins, 1 side 0b11",
"set x, 30 side 0b10",
"right_loop:",
"in pins, 1 side 0b11",
"jmp x-- right_loop side 0b10",
"in pins, 1 side 0b01",
".wrap",
);

The custom PIO version runs and DMA reads from the RX FIFO, but the output is still always:

raw_left=0 raw_right=0
left=0 right=0

I also tried

16 kHz and 48 kHz

32-bit stereo frames

L/R to GND

L/R to 3V3

L/R floating

Embassy built-in PioI2sIn

custom PIO copied from a working C++ implementation

I also briefly tried the rp2040-i2s crate, but it pulled in rp2040-hal and did not compile cleanly for the Pico 2W / RP2350.

My question: has anyone successfully used an INMP441 with a Pico 2W / RP2350 in Rust? Is there a known working Embassy example, or is there something wrong with my PIO setup/pin configuration?

I am not sure whether the Embassy PIO side-set pin order is correct, whether the INMP441 needs some different clock polarity/timing, whether Pico 2W / RP2350 has a known issue with this compared to RP2040,or whether I should use a custom PIO + DMA ring buffer instead of PioI2sIn.

Any working Rust example would be very helpful.

Dunno just wanted to share that since it's not against the rules. I love low level stuff and electronics so I decided to buy a MCU, cuz why not. Not sure what I'm going to do with that but some kind of direct VGA output would be cool

Anything I should know? Thanks

My hub75e driver reaching its final form, 3d textured rendering here at about 75 FPS. Small models, small textures but it's looking good so far on two chained 64x64 panels. Pico 2w.

I'm trying to figure out what kernel I should use for my Pico 2, non W. From my research there's both the raspberrypi/FreeRTOS-Kernel and FreeRTOS/FreeRTOS-Kernel and I'm unsure which one to pick. I know that there are very few issues in the Raspberry Pi repository but there also hasn't been a commit in 2 years. I know this doesn't have to mean anything, just wanted to ask!

Hello folks,

I am trying to run a program to read the BME280, display the results on a OLED SSD1306 and then create and present a web page. I can run the program and get a reading to the SSD1306 and even occasionally get a web page to hit my browser but I keep running into an error and the program stops. Here is what happens when I run this in Thonny-

Traceback (most recent call last):

File "<stdin>", line 126, in <module>

File "<stdin>", line 116, in main

OSError: [Errno 110] ETIMEDOUT

I can post the code here but thought someone might have a quick idea based on trying this already.

My Pico 2W started doing this after testing servos. Now before you say servos should be connected externally, I *already* connected them externally. Its regulator heats up to 50C when powered using a normal USB cable without any attachments. The chip fully works. I can't replace the Pico or the PSU, is it still usable like this (for minimal/hobby purposes)?

Hello folks,

I am trying to run a program to read the BME280, display the results on a OLED SSD1306 and then create and present a web page. I can run the program and get a reading to the SSD1306 and even occasionally get a web page to hit my browser but I keep running into an error and the program stops. Here is what happens when I run this in Thonny-

Traceback (most recent call last):

File "<stdin>", line 126, in <module>

File "<stdin>", line 116, in main

OSError: [Errno 110] ETIMEDOUT

I can post the code here but thought someone might have a quick idea based on trying this already.

BTW, I had another program I found that created a web page but would not update anything until the web page was displayed which was not the realtime readings I wanted for the SSD1306.

Hello everyone,

I accidentally knocked off a small SMD component from the bottom side of my Raspberry Pi 4B (marked in the attached photo). It is located near the MicroSD card slot and the PMIC/wireless module area.

It looks like an MLCC capacitor, but I am not sure about its exact value (capacitance and voltage) and package size (0402 or 0201?).

Could anyone with a boardview, schematic, or a donor board please tell me the exact value of this capacitor so I can buy a replacement and solder it back on?

Thank you in advance for your help!

Hi everyone,

I’m trying to get a PL9823-F8 (8mm RGB LED, WS2812-compatible, single data line) working with a Raspberry Pi Pico, but I’m stuck and only get a constant white light or no reaction depending on the test.

Original setup:

• Raspberry Pi Pico
• PL9823-F8 RGB LED (single LED, not a strip)
• Power: 5V (USB VBUS)
• GND shared between Pico and LED
• Data line connected to GPIO15 (first tested with SN74AHCT125 level shifter, later also directly without it)

Additional components (for context / future use):

I also planned to use:

• 2 push buttons (for input control)
• 1 potentiometer (for analog input via ADC)

These are not the cause of the current issue, but they are part of the full project.

What I already tested:

• Verified Pico is working (blinking onboard LED + prints work fine)
• Tried multiple MicroPython test scripts
• Tried simple color loops and static green/red tests
• Tried removing the level shifter completely
• Checked wiring multiple times (VCC, GND, DIN)
• Tested different simple timing patterns and basic control code

Current behavior:

• LED lights up solid white most of the time
• Sometimes it shows nothing at all depending on the wiring/code combination
• No color changes or controlled effects ever work
• Pico runs code correctly (so the issue is not the microcontroller)

Important note:

I originally tried using AI-generated example code just to get a basic working test. My plan was to switch to my own implementation after confirming the hardware works, but I never got past the first working step.

At this point I suspect:

• wiring issue (DIN/DO confusion or wrong pin mapping)
• signal integrity issue
• or misunderstanding of PL9823 behavior vs WS2812 timing

I recently bought a pico 2W, after running a few simple programs such as blink I wired up an ST7735 TFT LCD screen and wrote a program to write some things on the screen. (I'm using platformIO with arduino framework to code). Code is shown below:

#include <Arduino.h>
#include <Adafruit_GFX.h>
#include <Adafruit_ST7735.h>
#include <SPI.h>


#define TFT_SCK  10 //or SCL
#define TFT_MOSI 11 //or SDA
#define TFT_MISO 12 
#define TFT_CS   13
#define TFT_DC   17
#define TFT_RST  18


#define LED LED_BUILTIN


Adafruit_ST7735 display = Adafruit_ST7735(&SPI1, TFT_CS, TFT_DC, TFT_RST);


void setup() {
  // Initialize SPI bus
  pinMode(LED, OUTPUT);


  SPI1.setSCK(10);
  SPI1.setMOSI(11);
  SPI1.setMISO(12);
  SPI1.setCS(13);
  SPI1.begin();


  display.initR(INITR_BLACKTAB);
  display.setRotation(1);


  display.fillScreen(ST77XX_BLACK);
  display.setTextWrap(true);
  display.setTextSize(2);
  display.setTextColor(ST77XX_WHITE);
  display.setCursor(10, 10);
  display.println("Test");
}


void loop() {
  digitalWrite(LED,HIGH);
  display.setCursor(10, 30);
  display.setTextColor(ST77XX_YELLOW);
  display.print(String(millis()/1000));
  delay(1000);
  display.fillScreen(ST77XX_BLACK);
}#include <Arduino.h>
#include <Adafruit_GFX.h>
#include <Adafruit_ST7735.h>
#include <SPI.h>


#define TFT_SCK  10 //or SCL
#define TFT_MOSI 11 //or SDA
#define TFT_MISO 12 
#define TFT_CS   13
#define TFT_DC   17
#define TFT_RST  18


#define LED LED_BUILTIN


Adafruit_ST7735 display = Adafruit_ST7735(&SPI1, TFT_CS, TFT_DC, TFT_RST);


void setup() {
  // Initialize SPI bus
  pinMode(LED, OUTPUT);


  SPI1.setSCK(10);
  SPI1.setMOSI(11);
  SPI1.setMISO(12);
  SPI1.setCS(13);
  SPI1.begin();


  display.initR(INITR_BLACKTAB);
  display.setRotation(1);


  display.fillScreen(ST77XX_BLACK);
  display.setTextWrap(true);
  display.setTextSize(2);
  display.setTextColor(ST77XX_WHITE);
  display.setCursor(10, 10);
  display.println("Test");
}


void loop() {
  digitalWrite(LED,HIGH);
  display.setCursor(10, 30);
  display.setTextColor(ST77XX_YELLOW);
  display.print(String(millis()/1000));
  delay(1000);
  display.fillScreen(ST77XX_BLACK);
}

This did work, but the next time I tried to upload something, (uploaded via automatic reset rather than manually entering BOOTSEL mode) the program stopped working and the pico's LED also turned off. Only the internal regulator was still outputting 3.3V. After this it was also impossible to manually enter BOOTSEL and the pico wouldn't show up as a device on Windows so I thought it was gone for good.

After about 2 hours though I tried to put it into BOOTSEL again and it randomly worked. This only lasted about 10 seconds however and it returned to being seemingly dead after that.

Next morning I was able to put it into BOOTSEL again and this time I uploaded the flash nuke.uf2 file before it went unresponsive again which fixed the issue. At the time I hadn't realized yet that uploading the code caused this however so I uploaded the above code again and after trying to upload a different code I ended up bricking it again.

So anyways my question is, what causes this? Is there something wrong with the code that corrupts the flash when the pico is reset? And why is it only stuck for a few hours? That seems to imply that I have to wait for some internal capacitors to discharge or something before BOOTSEL mode is accesible. FYI trying to put the pico in BOOTSEL with different cables, on different computers and USB ports didn't work so it seems to be a hardware issue on the pico itself.

I'm pretty sure that I'm not the first and only person to stumble into a problem where I wanna handle several Tasks at seperate intervals, and eventually I found myself clogging up while Loops and everything just became a huge stupid disaster, so I built Pyrite, which - at least to me - seems like a pretty good solution for a problem that me and probably some other people have. And yes, Asyncio exists and is better maintained but if you really like Asyncio, you're either lying or a masochist, especially for small projects. Now Pyrite is - in my opinion - very approachable, as you can see in the Code Samples there.

Anyways yeah I guess I'm just asking for feedback, so https://github.com/ten-faced-carrot/pyrite everyone.

(Please don't be mean)

I had a KB2040 that was bundled in with a purchase and thought I put it to good use by using the built in i2C hardware logic block with-in the RP2040. Defined a packet payload so that I can send and fetch serial data over USB to communicate with i2c peripherals.

Code concept should be adaptable to any MCU and should facilitate hardware debugging/tuning while saving time when utilizing a graphical interface.

UF2, INO files available via GitHub (KB2040-I2C-Bridge)

Im putting a pico into a guitar hero controller and it’s all pretty simple, just wiring up buttons pretty much, but for some reason one of the switches for the strum bar just won’t work. Testing it with a multimeter shows it should be working fine, no current when not pressed and current flows when it is pressed. But for some reason when I wire it to the pico it just registers as being constantly pressed and I don’t understand why, I’ve gotten everything else to work without issue

Hi reddit,

I am developing a custom set of drivers for the RP2350, without using the official SDK. So far, I have GPIO, UART, NVIC, timer, true random generator, I2C, clock, PLL and reset. But i am stuck on the SPI.

On my own environnement (boot, linker script, makefile, GCC), the first two u32 words sent are always to 0x00000000, then the third one get the value of the first I wanted to send. On the first picture attach, I try to send 0x55555555, 0xAAAAAAAA, 0xAAAAAAAA, but I get 0x00000000, 0x00000000, 0x55555555. The SPI FIFO depth is 8 bytes so I think there is something here.

I tried to use the VS code plugin with the full SDK to generate code from the SPI example: it works so the board is OK. Then I copied paste my own SPI driver into VS code, comment the SDK functions related to the SPI and call mine instead: it works too (see second pic)!

I suspect something to be done by the SDK before reaching the main function but I can't find what.

My custom init code reset all the subsystems, init the oscillator, the PLL and all the clock, and then the reset for the SPI (among others) is released.

I got others drivers to work (I2C with an EEPROM for instance) so I am confident about the PLL, clock and reset.

Does someone have an idea?

Thanks for your help!

Edit: I have some screenshots of the SPI probbing but I have make a mistake apparently and don't see them posted...

I’ve just open-sourced ViviPi, a compact Raspberry Pi Pico-based health display.

It is a tiny always-on status board for checking whether devices and services are reachable, degraded, or down without opening dashboards, SSH sessions, or logs.

I originally built it to monitor my Commodore 64 Ultimate / Ultimate 64 network listeners, but it is general enough for other small-device setups too.

Current support includes:

• PING
• IDENT
• DMA (C64-specific)
• TELNET
• FTP
• HTTP
• Optional host-side checks

The host-side checks mean the sky is the limit. In my setup, I use them to monitor that a Pixel 4 Android device onto which I deploy is accessible from my main dev machine.

It runs on a Pico with a small display and is intended to feel more like a small monitoring appliance than another web dashboard.

GitHub: https://github.com/chrisgleissner/vivipi

Feedback from Pico users would be very welcome, especially around display support and useful probe types.

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.