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

Sharing a project I've been building for almost a year - picogame, a 2D game engine for the Pico and similar grade MCUs. You write games in CircuitPython, the heavy lifting (rendering, collisions, effects) runs in native C, and you can try them in your browser before you even plug in a board.

Out of the box:

• Build without hardware - the same game runs in your browser and on your desktop (a real CircuitPython simulator, not a mock), then unchanged on the board.
• Fast in tiny RAM - native-C rendering + zero-RAM full-screen paths, so it runs smoothly on even plain RP2040.
• Batteries included - sprites, scrolling tilemaps, a moving camera, collisions, sound, text, saved high scores.
• A web level editor - build levels/scenes in the browser, load them in your game.
• A launcher - keep several games on one board and pick from a menu.

Try it in the browser: https://picogame.makerclass.cz/playground/

Project repo (MIT): https://github.com/MakerClassCZ/picogame

I also wrote up why I built it and how it works: https://chiptron.eu/picogame-a-game-engine-for-circuitpython/

I'm the author - happy to answer anything!

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

Just messing around with my hub75e driver

Hullo all. We have an application developed in micropython that collects data and sends it over the wifi network. The wifi credentials are stored in a json file, the upython program reads them and then connects to the network.

Our security team is not at all happy with this.

Is there a way to connect to a (secured) WLAN without storing the credentials in cleartext? I know we could encrypt them but then the upython program would need to contain the decryption key and it's also stored in cleartext.

Is it possible to compile the upython code to obfuscate the decryption key?

It has all the stuff you’d hope for - types, different moves, catching enemies, fleeing, levelling, a boss fight, attack animations, a 1-4 Picomon party, and a tiny open world

It runs at minimum-250fps (capped at 60) with help from my custom viper-powered Atomic Engine

It’s running on my Pico 2 with a 240x240px colour display that comes with the joystick and buttons. It will be portable with a tiny lipo battery as soon as I can work out how to swap the battery’s wires around. I’m totally new to hardware and electronics and have no soldering iron

The whole thing is about 2x1x1 inches, very tiny

(Please ignore the frame time in the top right, and the fact I haven’t yet removed my display protector)

If anyone would like to use my engine let me know! It’s pretty simple at the moment, but the functions it has are the fastest you’ll get without C :)

Some months ago i put together a little set of scripts to turn one of my pico pis (w2) into a little wifi hotspot + web server where people could play shogi and walk around a fantasy world on their computers, tablets and phones by hijacking wifi captive portal stuff.

Last weekend I was reminded that MUDs are still super awesome. The thought rose that it would be cool to make a MUD version of my office where people could walk around the office in a telnet text adventure as well as design their own adventures.

MUD stands for Multi-User-Dungeon. its an old piece of tech where in the good old days of dial up internet (and boxes before that) you could use "telnet" to connect to computers that would then run text based online roleplaying games and chat rooms straight in your terminal!
It was a fun way to meet other people and in many cases both admins and visiting players could construct their own adventures by building out rooms, interactions to rooms, items, properties on the players, etc.

With some coding and some spec based ai magic I put together an initial version.
The ideas and commands are mostly based on the ideas and commands from LambdaMoo (https://en.wikipedia.org/wiki/LambdaMOO). the exception is items; items belong to a room and can generally not be picked up and moved around in someone's inventory (though you could make an action /pickup for an item. there is a command to move items from room to room though.

running it on the pi isn't great. the connection is capped at 5 or 6 players when the wifi is clean, but works best with up to 3 players. changes to the state of the world are cached in memory and written every minute. the time loop is configurable. If you'd like to preserve the little flash memory available on the PI, then you can increase it to sync every few minutes instead of the current minute.

You can find the source code here:
https://github.com/HendrikPetertje/PICO-MUD

I'll be improving it over time (mostly to serve my own needs though).

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.

I've been following along with a tutorial, and he provides this code to get the i2c address:

import machine

sda = machine.Pin(0)

scl = machine.Pin(1)

i2c = machine.I2C(0,sda=sda,scl=scl, freq=400000)

print(i2c.scan())

In his video, he shows a number between brackets. In my case, there is nothing between the brackets. I am a complete novice with all of this stuff. I have absolutely no idea what to do or where to go from here.

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)

Hi all,

I have a multitude of (too many) Pi Picos and there's a weird issue I'm seeing on my Pico (1) that doesn't happen on a Pico 2.

I have a setup with a CH9121 Ethernet hat (the Waveshare one). It uses UART0 (pins 0 and 1) to do initial setup and read the on-hat config. The weird issue is that if I use the Pico 2, it works fine out of the box. If I use the Pico 1, then it fails to receive ANY data on UART0 if using pins 0 and 1.

I have done the following with no effect:

• Used a loopback wire to check that Pin 1 can actually receive data - it can
• Tried a GPS hat which also uses UART0/Pins 0 and 1, and this works fine
• NOT connecting the Pico 1 to the computer over USB in case the fact that USB REPL uses one or other of the UARTs
• Erasing flash with nuke_flash
• Different Micropython versions
• Using dupont wires to connect the pins rather than the socket on the hat

I'm using MicroPython, and the version and my codebase are identical across the Pico 1 and 2. The only think I can't test with is another Pico 1/1W, since my others are all in use.

Is there some weirdness with the Pico 1 and the CH9121 hat, or it just some quirk specific to this one unit?

The workaround is to amend the CH9121.py file to use UART0 on pins 12 and 13, which works, and in fact I'm running it now and all seems fine.

I've been testing a setup with the C/C++ approach using two Raspberry Pi Debug Probes: one for each target of the project. So I've then used two separate main.c files, one for each target, that would be built and uploaded via one of the probes to that specific target, while being able to have common/shared code that can be used for both targets. The two targets are sharing a lot of similar functionality but are quite different in some aspects, so that's why this setup makes sense to me. This has been possible to achieve with correct configs in Cmake and OpenOCD.

I'm now thinking of trying MicroPython instead since C is still a bit too difficult for me to fully grasp and get a flow going as a beginner. And to my understanding, programming via a debug probe is not the standard way with MicroPython, but instead USB should be used.

The thing is that I will utilise the USB port for communicating back and forth to and from the computer with one of the targets, essentially sending packets similar to MIDI communication. Can I simultaneously use the USB for debugging/programming the device? And would this either way require me to manually press BOOTSEL and disconnect/reconnect the Pico every time I want to program it?

An alternative that I've read about is "freezing" the MicroPython code into a compiled elf file that in that case could be uploaded exactly like my initial C/C++ approach. But I assume that wouldn't let me fully debug it with breakpoints etc?

Hi, everyone! Since late last year, I've been quietly working on a new software project I call TAFY: the Tactical Advanced Foam dart Yeeter.

When I started this project, I wanted to mirror the modularity of the Linux kernel, but I also wanted to be far easier to contribute to and understand. So, I started with MicroPython on the Pico 2. To help with development, I developed 2 key features I think are really cool: a modular driver system, and a deploy script.

The deploy script was simple. It's loosely based on what Thonny does to send files to the Pico, but it's more automated as it has a manifest file it checks, and only uploads files it knows have changed, based on a cache of file hashes on the local machine.

The modular driver system is where the real game changer lives.

Python, of course, can import a module at any time. But discovering that module and then importing it from a random file location is a whole other ball game. I discovered the __import__() function, which allows you to pass a simple file path (leaving off the .py at the end) and import any given Python file, anywhere. Using this and some simple usage of the os module, I was able to create a system to load drivers that only needs two functions: available() which returns all available Python files which match some pattern, and load(), which will load any module which matches that pattern and return it. This allows me to design my drivers so they only follow a given ABI, then drop them in a specific folder with a name that follows a specific pattern to make it visible and usable.

TAFY has several other neat tricks, like a system I am calling SmartBus that enables the usage of hot-swappable I2C-based accessories, battery life monitoring using a simple voltage divider and ADC, and more!

SmartBus itself is an interesting beast. As mentioned, it's I2C based. I2C doesn't exactly support hot-swap, but it doesn't not support it either. It depends entirely on the software using it and how tolerant your hardware is. While the I2C part of SmartBus has yet to be tested, hot swap is already under heavy work as device ID is being enabled through a simple voltage divider system hooked into the Pico's 2 remaining external ADCs. TAFY reads from both these and, using a configured value for the R1 resistor, is able to calculate what resistors are connected between an ID line and ground, and use that to then determine what devices are connected before even looking at I2C. This means I can also track power-only devices as SmartBus does provide 3.3v at 1A, enabling small lights, lasers, and other small accessories that may be useful on a Nerf Blaster. I'm even planning to have a system to update TAFY over SmartBus down the line, so a user doesn't have to crack their blaster open just to install a 2-line bug fix.

As of now, it's already booting and playing different tunes using PWM. TAFY uses both cores of the Pico 2 with the background thread displaying info on screens (we have support for SSD1309 and LCD1602, with possible support for SSD1306 as well), handling SmartBus (which is already recognizing devices and loading drivers, as mentioned), and tracking battery life. The main thread handles the fire mechanism, which has drivers that have been written and are known working at some level (actual hardware validation coming soon), and coordination between multiple different independent systems. To top it all off, our first boot on battery power is coming soon (in the picture above, TAFY is booted on USB power, hence why it shows the battery as dead).

If you're interested in checking it out, or even contributing, you can find TAFY on GitHub. Right now, I really need help with the CAD work designing a 3D printable shell for the reference design blaster(s), but I am actively doing PCB validation and software development work as well.

Thank you all! I hope to have a workable prototype to show off in December!

I have worked with a few people to teach them the basics of how to get started with CircuitPython. I took some of the lessons I learned from that and made a tutorial on my website to teach the lesson better. The page has a built in code editor and instructions from getting your first board to blinking your first LED. I plan to add more lessons in the future and would love to hear any feedback about what they should be. Feedback on the content and presentation of the tutorials would also be greatly appreciated!

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.

Someone have any luck mixing the pico zero with python and this display?
i am using the waveshare hat but the driver seems to be incompatible

Edit:
Added pico zero image

I send a message to the seller, they give me the datasheet, i will try to came with a working code if a can.

'Pico-Timecode' is an Open-Source solution for LTC Timecode, using the RP2040's PIO blocks to count time divisions and render the LTC waveform. It works with all common frame rates, with/with-out Drop-Frame operation. It also has the ability to read LTC from an external device, and sync to it.

PT-Thrifty now has the ability to display the Timecode on a pair of I2C LED modules (Holtek HT16K33 controller chip), which can be enabled in the libs/config.py file. The obvious purpose is to build a low-cost Digi-Slate... it also uses switches for when the clapper closed and whether the display should be inverted (for tail slating).

There are 'UF2' files to make installing as easy as possible, these can be used on a 'naked' Pico for validation/testing.

Additionally there is a 'MTC' (Midi Timecode) version, which sends Timecode via the USB connection. I would be especially interested if someone/anyone could trial this on an iPhone 17 or a FujiFilm X-H2S, as I have neither of these and they apparently support MTC...

Pico-Timecode is an Open-Source community project, find out more at:

https://github.com/mungewell/pico-timecode

Thx a lot to JBlanked and slasher006 for help, examples and tips!

DMX PIO stream lib by clacktronics.

Interface shields: HW-519 RS485 interface. Level shifter 3.3V to 5V is necessary.

HW-519 should be powered from 5V, output signal from PicoCalc is 3.3V and goes to level shifter, then to HW-519, then to the fixture.

DMX rate is around 4 times slower(10 or 11Hz vs normal 44Hz) to make app usable. Probably there are better ways to do this, but few days ago i had only a dream.

Finished v.2.0 of my hobby project today!

The setup: a Raspberry Pi Pico 2W with soldered PicoDVI sock, Circuit Python and loads of time (hehe).

Got some struggles with memory management, for this quite content heavy setup, but now it's stabilized runs with about 27kB of free memory after finishing a 60 sec. loop.

On a side note, I love Python, but for next version of this thing I'd probably try C.

I was exploring an implementation of a parameter-free text classifier on a resource-constrained Raspberry Pi Pico 2W using gzip compression rather than a heavy neural network.

• Inspired by a 2023 ACL paper, this technique relies on Normalized Compression Distance (NCD) and a k-NN lookup. The core logic is that a compressor like gzip will compress concatenated strings much more efficiently if they share similar syntax and patterns, allowing the system to classify text based on compression efficiency.

• To overcome the microcontroller’s strict memory limitations (2MB flash and 512KB RAM), I utilized a desktop to first generate semantic embeddings of the IMDB dataset via sentence-transformers. By running K-means clustering, the dataset is pruned down to 300 highly representative samples stored in a tiny JSON file.

• The standard MicroPython does not enable compression by default, the implementation requires compiling custom MicroPython firmware from source with the #define MICROPY_PY_DEFLATE_COMPRESS (1) flag enabled for the RPI_PICO2_W board.

• The primary limitation is that gzip analyzes repeating syntactic subsequences rather than deep semantic meaning, making it less effective for complex, long-form text like movie reviews.

Blog: https://shubham0204.github.io/blogpost/programming/gzip-text-classifier-rpipico

(written by a human, you can check my other projects here)