I love the Pico product line and think they are severely underutilized. Many Pi 3/4/5 projects can be performed with one of these little guys. Don’t chain yourself to a whole Linux distro unless you really need it.
What I'll never understand about this whole thing is why most people seem to easily tolerate the rigamarole of maintaining an entire host SBC OS and sending or even cross compiling binaries to it, for microprocessor work. I much prefer maintaining a dev env on machine(s) and sending and flashing a binary over the wire. Maybe I just dislike state, but the pico (and several other MCU ecosystems these days) make it so easy to
Like: I suck at code. But I've known how to walk around in *nix systems and use things like bash to chain together commands like awk, grep, and sed for ~30 years. Maybe I'd even toss in some badly-cooked perl or python (or both!), when that seemed necessary.
For a very long time, I've been able to get some things done, but my skillset was focused on doing these things with real computers with live filesystems and real user interfaces, not MCUs.
So, some years ago: When I wanted to turn a window fan on and off based on some network-retrieved weather conditions, I didn't even consider an MCU. I didn't want to learn a new way of doing things; I just wanted a computer to get some data and decide whether to turn the fan on and off. And I wanted that done sooner instead of later.
I accomplished this with a Raspberry Pi Zero W -- with the whole OS. I didn't cross-compile anything. I didn't have to target some weird-looking external environment, or learn a new way of doing things.
Setting up the dev environment was very familiar: Dump a binary onto an SD card, boot it, get it onto the network, and use it.
I just SSH'd into that tiny little computer like I would any other Linux box and wrote my stupid little cobbled-up scripts right there, in-situ, on the final device that would be performing the work -- with a familiar interactive shell.
The end result worked very well. I'm not ashamed of any of this at all.
---
Later, I switched from networked weather reports to an RTL-SDR dongle and software decoding to listen for over-the-air broadcast reports from someone else's nearby APRS weather station, and used that as a source of weather data instead.
Can we even get that done in MCU land? (Should we even try to do so for just one window fan?)
I'm sure you're aware, but for the record the Pico has state. That's one of the best things about it. You have a very fully featured Python environment (or rust, or C) with a read/write filesystem. The WiFi SDK is also super useful. They can make HTTP requests (and HTTPS without full CA validation), host an HTTP server, even host an access point.
I’ve been experimenting with the new Raspberry Pi Pico 2 W (RP2350) and wanted to see how difficult it would be to build a fully compliant Matter smart device from scratch using Rust.
I put together a complete "Blinky" example using the rs-matter stack and the embassy async framework. It uses BLE for the initial commissioning phase and Wi-Fi for network connectivity. Once flashed, you can provision it directly into Apple Home, Google Home, or Home Assistant using your smartphone—no cloud accounts required. It exposes a standard Matter On/Off cluster that toggles a physical LED wired to the GPIO pins.
A few interesting technical notes from the build:
Bare Metal: It runs entirely no_std on bare metal using embassy-rp.
Radio Coexistence: Getting the CYW43439 wireless chip to handle concurrent BLE (for commissioning) and Wi-Fi (for Matter IP traffic) on the RP2350 took some tweaking. We actually had to dial back the PIO SPI clock divider specifically because the RP2350's faster 150MHz core clock was causing bus corruption when the radio was saturated!
Async Rust: The repo includes the full async CoEx (coexistence) runner setup to safely multiplex the radio between the Bluetooth and Wi-Fi stacks concurrently.
If you’ve been wanting to build local-only smart home devices but felt intimidated by the massive official C++ Matter SDK, doing it in Rust is actually becoming incredibly approachable.
Would love to hear if anyone else is building custom smart home gear in Rust.
The initial approach was to run BLE and Wi-Fi simultaneously. Provisioning sometimes worked. It seems like there was some interference. Then switched to run BLE with Wi-FI off. When I got Wi-Fi credentials, switched BLE off, and turned Wi-Fi on. It still had some issues. Turned out when slowed down SPI bus, it started working. Only tested with Home Assistant and have to fork and patch rs-matter-embassy
Use a digital storage scope, many of them can directly decode protocols like SPI . Then a lot of trial and error to figure out when exactly the issue happens and what else is happening around that time.
I love the Pico product line and think they are severely underutilized. Many Pi 3/4/5 projects can be performed with one of these little guys. Don’t chain yourself to a whole Linux distro unless you really need it.
What I'll never understand about this whole thing is why most people seem to easily tolerate the rigamarole of maintaining an entire host SBC OS and sending or even cross compiling binaries to it, for microprocessor work. I much prefer maintaining a dev env on machine(s) and sending and flashing a binary over the wire. Maybe I just dislike state, but the pico (and several other MCU ecosystems these days) make it so easy to
The advantage is familiarity, I think.
Like: I suck at code. But I've known how to walk around in *nix systems and use things like bash to chain together commands like awk, grep, and sed for ~30 years. Maybe I'd even toss in some badly-cooked perl or python (or both!), when that seemed necessary.
For a very long time, I've been able to get some things done, but my skillset was focused on doing these things with real computers with live filesystems and real user interfaces, not MCUs.
So, some years ago: When I wanted to turn a window fan on and off based on some network-retrieved weather conditions, I didn't even consider an MCU. I didn't want to learn a new way of doing things; I just wanted a computer to get some data and decide whether to turn the fan on and off. And I wanted that done sooner instead of later.
I accomplished this with a Raspberry Pi Zero W -- with the whole OS. I didn't cross-compile anything. I didn't have to target some weird-looking external environment, or learn a new way of doing things.
Setting up the dev environment was very familiar: Dump a binary onto an SD card, boot it, get it onto the network, and use it.
I just SSH'd into that tiny little computer like I would any other Linux box and wrote my stupid little cobbled-up scripts right there, in-situ, on the final device that would be performing the work -- with a familiar interactive shell.
The end result worked very well. I'm not ashamed of any of this at all.
---
Later, I switched from networked weather reports to an RTL-SDR dongle and software decoding to listen for over-the-air broadcast reports from someone else's nearby APRS weather station, and used that as a source of weather data instead.
Can we even get that done in MCU land? (Should we even try to do so for just one window fan?)
I'm sure you're aware, but for the record the Pico has state. That's one of the best things about it. You have a very fully featured Python environment (or rust, or C) with a read/write filesystem. The WiFi SDK is also super useful. They can make HTTP requests (and HTTPS without full CA validation), host an HTTP server, even host an access point.
Languages:
75.4% Linker Script
18.2% Rust
6.4% Shell
About sums up embedded development in Rust.
Most of the code is already in libraries. rs-matter includes a lot of batteries, so for simple clusters you end up writing little code.
It looks like github is just buggy in this case.
Hi HN,
I’ve been experimenting with the new Raspberry Pi Pico 2 W (RP2350) and wanted to see how difficult it would be to build a fully compliant Matter smart device from scratch using Rust.
I put together a complete "Blinky" example using the rs-matter stack and the embassy async framework. It uses BLE for the initial commissioning phase and Wi-Fi for network connectivity. Once flashed, you can provision it directly into Apple Home, Google Home, or Home Assistant using your smartphone—no cloud accounts required. It exposes a standard Matter On/Off cluster that toggles a physical LED wired to the GPIO pins.
A few interesting technical notes from the build:
Bare Metal: It runs entirely no_std on bare metal using embassy-rp. Radio Coexistence: Getting the CYW43439 wireless chip to handle concurrent BLE (for commissioning) and Wi-Fi (for Matter IP traffic) on the RP2350 took some tweaking. We actually had to dial back the PIO SPI clock divider specifically because the RP2350's faster 150MHz core clock was causing bus corruption when the radio was saturated! Async Rust: The repo includes the full async CoEx (coexistence) runner setup to safely multiplex the radio between the Bluetooth and Wi-Fi stacks concurrently. If you’ve been wanting to build local-only smart home devices but felt intimidated by the massive official C++ Matter SDK, doing it in Rust is actually becoming incredibly approachable.
Would love to hear if anyone else is building custom smart home gear in Rust.
This looks very interesting. Thanks for sharing!
> bus corruption when the radio was saturated
How do you even diagnose this?
The initial approach was to run BLE and Wi-Fi simultaneously. Provisioning sometimes worked. It seems like there was some interference. Then switched to run BLE with Wi-FI off. When I got Wi-Fi credentials, switched BLE off, and turned Wi-Fi on. It still had some issues. Turned out when slowed down SPI bus, it started working. Only tested with Home Assistant and have to fork and patch rs-matter-embassy
2 replies →
Use a digital storage scope, many of them can directly decode protocols like SPI . Then a lot of trial and error to figure out when exactly the issue happens and what else is happening around that time.
[flagged]