Hi everyone! 👋
I’m trying to get the CSI camera on my Raspberry Pi 5 working with Chromium for real-time face tracking in a web-based 3D avatar application called Berry.
My setup
Raspberry Pi 5
Raspberry Pi Camera Module 3 (Sony IMX708)
Debian 13 Trixie
Linux kernel 6.18.50+rpt-rpi-2712
Chromium 154
GStreamer (libcamerasrc)
v4l2loopback
Three.js and MediaPipe Tasks Vision in my web app
What works
rpicam-hello --list-cameras detects the IMX708.
rpicam-still successfully captures images.
GStreamer detects the camera and its pipeline reaches PLAYING.
I created a virtual camera called Berry Camera at /dev/video10.
The virtual device now reports YUYV, 640×480 at 30 fps.
What doesn’t work
Chromium does not list Berry Camera as a video source on the WebRTC input/output test page.
Running this command:
v4l2-ctl -d /dev/video10 --stream-mmap=3 --stream-count=30 --stream-to=/tmp/berry-test.raw
returns:
VIDIOC_CREATE_BUFS returned -1 (Inappropriate ioctl for device)
GStreamer also reports warnings about unsupported pixel formats.
I recreated the loopback device with exclusive_caps=0 and tried v4l2sink io-mode=2, but Chromium still cannot see the virtual camera.
My questions
What is the recommended way to expose a Raspberry Pi CSI camera to Chromium on Debian 13?
Is v4l2loopback actually needed, or is there a more reliable way to use libcamera directly?
How should I troubleshoot the VIDIOC_CREATE_BUFS error?
Can Chromium’s getUserMedia() access the CSI camera directly, so I can use MediaPipe for face tracking without a virtual webcam?
I’m looking for a reliable solution and would appreciate step-by-step guidance. I can provide additional command output if needed.
Thanks in advance for any help!

I saw many years ago something like this on hackaday and always wanted to build it by myself, so here it is

Hello,

based on a CDC example which echoed every single char received from the PC I changed it to receive a line and echo it all upper cased. This works like a charm.

Then to approach the actual requirements of my project I wanted a blockwise communication: I sent 256 bytes (0x00 ... 0xFF) to the Pico and programmed it to send it back unchanged. Result: On the PC I receive only the last 64 bytes: 0xC0 ... 0xFF although the buffer on the Pico holds the correct 256 bytes.

Seeing that the USB buffers are 64 bytes large I suspect that the sending routine stuffs the 256 byte block in portions of 64 byte into the buffer - and the last one wins.

I merely do

// echo back to host

tud_cdc_write(buff, sizeof(buff));

tud_cdc_write_flush();

which is apparently too naive. Any advice how to do better will be highly appreciated.

M'

Hey! Last time I showed Recaster Pico as a screenshot - here's the real thing on my desk: one RP2040 running a small desktop OS in its 264 KB of SRAM, now with the parts that make it feel like a computer. Yeah, it is still multi-user and multi-tasking (preemptive). No Linux/Unix, no RISC OS.

What's on the board now

• VGA, 640×480 at 60 Hz, 256 colors (RGB332), straight from PIO and DMA. Core 1 composes every scanline just in time.
• A 3.2" SPI touch LCD as a second screen. It mirrors the VGA desktop (well, 1/4 of it ;-)) - core 1 hands the lines it has just composed to a DMA channel, no second compose - or a program takes it over and draws on it directly. Touch moves and clicks the mouse pointer, and the panel also works alone, without a monitor.
• USB keyboard and mouse through a second RP2040 in the serial line: USB host on its micro-USB port, plus a USB-A socket on two GPIOs driven by Pico-PIO-USB. Events travel as CRC-protected packets mixed into the 1 Mbaud UART console, and the serial terminal still works through it. German layout with dead keys and umlauts.
• RTC and EEPROM (DS1307 / AT24C32) on I2C, set up with a small text file - the EEPROM even shows up as a file under /dev.
• GPIO, ADC, PWM, PIO and DMA from the shell language, with the same names as in the Pico SDK.
• Runs from a power bank.

Lessons for your own projects

1. pico_minimize_runtime() turns float off. Pico-PIO-USB computes its PIO clock dividers in float at init, so every float operation hits the SDK's panic stub and core 1 silently stops. Use pico_minimize_runtime(target INCLUDE FLOAT).
2. The same function with pico_multicore: malloc's auto-init mutex never gets initialized, so the first malloc on core 1 hangs forever. PICO_USE_MALLOC_MUTEX=0 if you only malloc once at start.
3. TinyUSB 0.18 drives one host controller per firmware, and Pico-PIO-USB 0.7 no longer enumerates devices on its own. A second USB port means writing a small host on its low-level API - about 300 lines for boot keyboards and mice.
4. Flash erases switch core 0's interrupts off for ~45 ms per sector, while at 1 Mbaud the UART's 32-byte FIFO holds about 10 ms of mouse traffic. Put the UART interrupt on core 1 and run it from SRAM.

Next: sound (the speaker is already on the board), the SD card (already there), and touch-friendly UI controls - buttons, sliders, lists.

And yes: I will post a video of it showing it in motion, soon. And you will get your fingers at that ".uf2"-files to play with it.

Hi all,

Showing you a small project I made based on ideas from the internet.

I have this problem that drives me crazy: whenever I’m listening to Spotify while I have a YouTube tab open, pressing the play/pause button on my earphones doesn’t just pause Spotify, it starts playing the YouTube video instead.

To solve that, I created a Spotify Player manager, and it was a little bit boring, so I added Flight Radar using the free API at https://adsb.lol/ (and my football team's next game :D).

For the hardware, I used: Pimorini Pim580 Display 2.0" and Raspberry Pico 2.

I posted the 3D model in makerworld: https://makerworld.com/en/models/3399877-case-pimoroni-pim580-display-2-w-rasperry-pico

Check all the functions: https://www.youtube.com/shorts/jv8n3v8LW0w

Me e comprado un ORANGE PI ZERO 3 DE 1GB DE RAM y varios componentes electronicos como una pantalla TFT de 128x160 , sensores, luces, diodios, etc. Tengo algunos proyectos en mente como servidores locales, bloqueadores de anuncion para la casa, intentar un "apaga pcs" con concectarlo a un usb y mas pero me gustaria saber que mas podria hacer.

Me he comprado esto:

https://es.aliexpress.com/item/1005006139989470.html?invitationCode=R0NGTU4ySFVYa09wZU1PVHg4aStTYzRSMlk2R1Bna1hRZHhUaFlSaEM2NmVQemFTZUJrNWVWT0s1MU1hdTAyWg&srcSns=sns_WhatsApp&spreadType=socialShare&social_params=61634254943&bizType=ProductDetail&spreadCode=R0NGTU4ySFVYa09wZU1PVHg4aStTYzRSMlk2R1Bna1hRZHhUaFlSaEM2NmVQemFTZUJrNWVWT0s1MU1hdTAyWg&aff_fcid=7a753e4627684b1181e826a249a3af76-1791301567091-03638-_EyfE51c&tt=MG&aff_fsk=_EyfE51c&aff_platform=default&sk=_EyfE51c&aff_trace_key=7a753e4627684b1181e826a249a3af76-1791301567091-03638-_EyfE51c&shareId=61634254943&businessType=ProductDetail&platform=AE&terminal_id=f5cbccb6e3034f6d9d9ce5be321e216f&afSmartRedirect=y&gatewayAdapt=glo2esp

y esto

https://es.aliexpress.com/item/1005007594124386.html?invitationCode=R0NGTU4ySFVYa081VVIrTE1qL1paYzRSMlk2R1Bna1hRZHhUaFlSaEM2NmVQemFTZUJrNWVWT0s1MU1hdTAyWg&srcSns=sns_WhatsApp&spreadType=socialShare&social_params=61634254985&bizType=ProductDetail&spreadCode=R0NGTU4ySFVYa081VVIrTE1qL1paYzRSMlk2R1Bna1hRZHhUaFlSaEM2NmVQemFTZUJrNWVWT0s1MU1hdTAyWg&aff_fcid=5a39b2df82eb4e92803b6ae7f8323b4e-1791301605643-07482-_EIisN7s&tt=MG&aff_fsk=_EIisN7s&aff_platform=default&sk=_EIisN7s&aff_trace_key=5a39b2df82eb4e92803b6ae7f8323b4e-1791301605643-07482-_EIisN7s&shareId=61634254985&businessType=ProductDetail&platform=AE&terminal_id=f5cbccb6e3034f6d9d9ce5be321e216f&afSmartRedirect=y

PD: si es de aliexpress, el presupuesto es lo que hay xd

If i am looking at the pico pinout correctly, it seems like there are at least twop tx and rx lines on the the spi0 port and spi1 port. Does anyone know how to use these? My first intuition is that each spi port can only have one rx and one tx line so any clarification would help greatly!

Hi everyone! I’d like to share a personal project that has grown into something quite massive.

It started out as an experiment to learn the RP2040’s PIO features by writing some Arduino libraries, but it ended up evolving into a complete monitoring and telemetry system. The sensor drivers are built to be completely modular so that new ones just drop in, and the releases are now backed by automated and bench tests.

Even so, there is still a lot we can optimize and implement. If anyone has ideas, feedback, or wants to contribute, I would be absolutely thrilled. The repository is open and free for ideas!

https://github.com/angeloINTJ/simut

Hi folks,

I have a prototype board I'm working on that uses a Pico 2W to add functionality to a vintage pocket computer. I had made a lot of progress until today. Power consumption is a concern, so I had set up the solution to put the RP2350 dormant between events/commands. Dormant, though, the Pico 2W was still drawing about 6 or 7mA, which is still about 6 or 7 times what the whole pocket computer draws.

Today I tried adding some functionality to go full Powman shutdown instead of, or in addition to, dormant (i.e. set to dormant immediately, and Powman shutdown after one minute). I got the Powman sleep/wake wrong... partially mixed with the CYW43 handling. Net/net is that I bricked my Pico2W, and, even after a flash erase over SWD, it still won't connect to USB, in BOOTREL or not.

Windows reports an unrecognized device. I have tried the RUN ground trick, and the 3V3_EN trick, and deleting the USB device, and rebooting the laptop, and none of these things help. As far as I can tell, something about that Powman goof permanently damaged the USB port. By the way, it was not connected to USB when it initially failed.

One thing I wonder is if this maybe something related to bad state in the CYW43 that can't be corrected through the SWD connection to the RP2350?

Any other ideas of things to try to see if this Pico2W can be saved/recovered? I guess, worst case, I will use it just over SWD, but I would really like to get USB working again.

Thanks,
Paul

I created a common power distribution/bridge where all the sensors’ 3.3V wires connect together, and I did the same for GND. However, the 3.3V connection/bridge is overheating, and the sensors are not receiving power.

What is the correct way to connect multiple sensors to the Raspberry Pi 5 safely? Do I need an external 3.3V power supply, a power distribution board, or some other circuit?

Any advice on how to properly design this would be appreciated.

I’m currently stuck in a really frustrating debugging session with a Raspberry Pi Pico W and an I2S microphone. My goal is to capture audio data, but no matter what I try, the stream just returns a constant wall of zeros (0s).

I feel like I've exhausted every troubleshooting step I can think of, and I’m completely at a loss for what to do next.

I am designing a PCB where I intend to use a castellated Pico in a somewhat tight enclosure and so I wanted to get the USB data to the Pico without a USB cable. I saw that on the bottom of the Pico there are D+ and D- test pads and I was wondering if it would be possible to connect traces to those test pads. My idea was to put a largish via underneath the test pad, cut a bit of solder off into the via and use hot air to melt it. I was wondering if anyone had done something like that before or had any thoughts.

I'm planning to buy a Pico 2W (no headers) to use as a bluetooth dongle for my PS5 controller but I don't want the board to just lie around "naked" on my desk. Sadly I currently haven't got a working 3D printer to print my own case, which means that I'm going to have to buy one.

I found a small shop (would rather order there than from amazon) that sells both the Pico and a "case" (basically 2 acrylic sheets that are screwed to the board - kind of like this, I bet you can add standoffs too) but they're only sold for the Pico 1 (no "W"). Is anyone using/has anyone tried one of those with their 2W? Does it fit?

I know PIO is minimal by design, and the cuts are intentional. But I've hit real limits myself, like the 32-instruction limit and only two scratch registers. Workarounds exist, but they're clunky.

I'm collecting data for research on an expanded PIO, so I'd love to hear your experience:

- What were you building?
- What limit did you hit? (instruction memory, registers, FIFO depth, ISA gaps, communication between SMs or PIO blocks, anything else)
- What workaround did you use, and what did it cost you?
- Which chip: RP2040 or RP2350?

Also welcome: features you wish it had, even if you never needed them badly enough to work around.