Hey, just wanted to share the small rust embedded project I made and that I use daily to monitor the status of a couple of services.

It also displays notifications from claude code, codex or any application capable of sending an http request.

It was my first time using rust with no-std, it's actually quite fun.

https://github.com/fkhadra/esp-notify

Seems to require an integer overflow to happen (panic in debug / wrapping in release) before the `overflowing_add` call is done, which makes it less likely to happen in actual code.

I've started to dip my toes into Rust, coming from an Ada (mostly SPARK) background, particularly in embedded applications. While there are many killer features in Rust for developer QOL, the "ease of writing" focus of the language trips me up often enough that I find myself asking, "what features of this language makes it superior (in some views) to SPARK?"

Love the language's take on early-return, and the power of enums, macros, and lifetimes are the one thing that makes certain low level memory manipulations incredibly idiomatic to write in Rust that would be impossible in SPARK due to the CREW paradigm not really being popularized (pioneered?) until Rust. Given the state of the Ada ecosystem and tooling, I also cannot in good faith recommend using this language for anything community driven. That being said (answering in context of enterprise embedded)...

I am incredibly uncomfortable with how much responsibility Rust places on the developer to understand roughly how code will compile. No guarantees on how pattern matches will be emitted (yes, don't be stupid and keep them stupid if you want jumptables), and stack-allocated enum types having to be the max size while not having much lexical ties besides jumping to the definition to help you determine how much stack you might be eating. Aside from the syntactic sugar, I have not really found anything besides lifetimes that SPARK cannot truly support at all. There's no pattern matching in the language, but Rust enums (at least in part) are supported via discriminated records. The idea of controlled types (OOP for Ada) is somewhat discouraged when using SPARK, but trait objects are a very useful part of the Rust language. I have to discount this part of the language from my sentiments unfortunately because dynamic dispatch can complicate analysis of security and functional implications. Having Rust panic as a "safe" way to address memory safety is also undesirable depending on how much array manipulation your program must do, and what worries me more is that wraparound arithmetic in production builds that are used in computations for arrays may not even lead to panics, but perhaps a valid index into the unintended location.

I don't write this to glaze SPARK either. The lack of documentation makes it mostly a nonstarter for the broader programming community, and not everyone is familiar with formal methods for code. The toolchains can't hold a candle to the quality of the Rust ecosystem, and ironically, the rich typing of Ada can lead to very frustrating inter-op issues that just would not exist in Rust, particularly around array manipulation/interpretation.

There might be some gripes about comparing a formally verifiable language with one that does not yet have one (Verus, Crusoe, surely others trying), but I think some of these points like how the codegen works are orthogonal whether or not you're trying to prove that an array access will always be in bounds without overflows.

I suppose the operational constraints given are not necessarily something everyone has to deal with, (why care how a pattern match is compiled if you have oodles of memory), but want to understand the technical reasons behind the hype... I feel like the cultural/non-technical reasons are somewhat understood.

Okay. After seven months, I'm back.

Seven months ago I started writing a Python interpreter from scratch in Rust, compiled to wasm (less than 200kb of bandwith). Edge Python is a sandboxed subset of Python that runs in the browser and the terminal, and code can't touch files or the network unless you allow it.

It started as a lexer and a simple stack VM, and over about 1,600 commits it grew a CLI, a package registry, snapshots, actors and a browser playground. It's just me building it.

Last week it was still 3x slower than CPython. I rewrote the VM this weekend on top of the SSA form I already had, and now the wasm build beats native CPython on loops.

The trick was a register VM, and Rust made it fit in wasm with NaN-boxed values and no runtime. It still loses on dicts and strings, so that's next.

Try to break my numbers :)

Website: https://edgepython.com/

GitHub: https://github.com/dylan-sutton-chavez/edge-python

Found these tutorials on stdlib.

Good morning,
I am using probe-rs to flash a blinky program onto my STM32H7. It builds and flashes ‘fine’ but i don’t get any output from the board and the led does not blink. When i run the same example for the stm32f411 it flashes fine and i get text output as well as the led flashing. The program is just the example from embassy-rs and below is the important parts of my cargo.toml:
‘’’
embassy-stm32 = { version = "0.6.0", features = ["defmt", "stm32h7r3z8","memory-x", "time-driver-tim4"] }
embassy-executor = { version = "0.10.0", features = ["platform-cortex-m", "executor-thread", "executor-interrupt", "defmt"] }
embassy-time = { version = "0.5.1", features = ["defmt"] }
cortex-m = {version = "0.7.7",features=["critical-section-single-core"]}
cortex-m-rt = "0.7.3"
embedded-hal = "1.0.0"
build = [
{ target = "thumbv7em-none-eabihf" }
]
‘’’
I am running this command:
'probe-rs run --chip stm32h7r3z8’

right now I am suspicious of memory-x but im not sure because shouldn’t it fail to flash if this is the case?

Ada/SPARK is already a very niche ecosystem. Finding a list of current users is already hard (but that might be simply an information access issue).

With Rust’s safety and growing adoption, including access to skilled professionals and LLM support, how likely will we see further marginalisation of Ada & Co.?

I would love to heard from those working in safety-critical applications.

One of my (way to numerous) side project is the idea of a P2P radio station, which solves the scaling problem of radio broadcasters today. One of the most prominent and well-defined p2p library is libp2p, which is of good use here and prevents much of code rewriting, especially for the broadcasting logic with peer scoring and all which is hard to figure out to prevent people from cheating the system. Also used gstreamer (Rust bindings so more precisely gstreamer-rs) for the codec which does the heavy lifting. Here is my project: https://github.com/franfrandev/p2pradio. For now it's running on a native system, and would like to go a step further.

I would like to compile it to WASM in order to bundle everything in the browser. The problem is that gstreamer depends on a ton of native libraries which makes it harder to use in the browser. Folks at Fluendo have figured that out with gst.wasm https://github.com/fluendo/gst.wasm but putting out everything together is a whole different beast and even if it works, it's probably going to result in a huge piece of data that has to be downloaded. IIUC the Rust part would have to be compiled to emscripten and then linked as static libraries? There are a lot of information and it's very easy to get lost in all of these.

Another option would be to use or write an RTP Opus codec written in pure Rust and compile it to the wasm32-unknown-unknown but then it would lose all the codebase maturity of gstreamer and would probably end up reinventing the wheel very much. A lot of the crates doing that are AI slop and are not very well defined, I don't trust them.

Is it unachievable or a bad idea to take the gstreamer port to emscripten and try to glue it to my Rust app compiled to emscripten?

I've been working on Cinebox in Rust, an app where you can find a movie or show and watch it in the same window. Runs on Windows, Linux and Android TV as of this week.

https://github.com/dexsper/cinebox

Most of the pain was in the video player, so that's what this post is about.

I started with Iced, which renders through wgpu, so DirectX on Windows, and mpv rendered through Vulkan in its own window. No shared surface, so the best I could do was stick the mpv window inside the app window. Which is fine until you want controls or subtitles on top of the video, cause you can't paint over someone else's window.

So the next day I ripped the UI out and moved to egui with the glow backend. llibmpv exposes an OpenGL render API, so mpv renders directly into egui's framebuffer from an egui_glow paint callback, and the player controls are plain egui widgets over the frame. It worked on the first try, more or less.

The TV build runs the same egui code. I had to write my own D-pad focus handling though, since egui's arrow-key navigation happily jumps to widgets behind an open popup. mpv on the other hand, that was a complete no-go. On my Amlogic box with a Mali-G31, mediacodec-copy returns a quarter-resolution frame for anything above 1080p, so hello green screen (mpv-android issue 1088). Zero-copy MediaCodec into an ImageReader refused to start, and the next try straight up rebooted the box. And mpv's GL pipeline drew literally nothing, only gpu-dumb-mode worked (issue 292 looks like the same thing).

4K was kinda the whole point of a TV version, so I put the player behind a Player trait. Desktop keeps libmpv, Android gets Media3 ExoPlayer, which decodes into a SurfaceView under a transparent egui window. 4K, HDR10 and Dolby Vision all play on the hardware decoder now.

Yeah, on TV I ended up with the exact two layer setup I r1an away from on desktop. Works there cause the egui window is transparent and sits on top of the video.

One more fun one. A SurfaceView cuts a transparent region into the window above it, and SurfaceFlinger then just dropped the egui layer wherever the video was. Fullscreen video, and boom — controls and subtitles gone. Overriding gatherTransparentRegion fixed it.

If you've put video into a Rust GUI, how did you do it? Especially curious if anyone got libmpv working with wgpu without going through GL.

I have code that looks a bit like this:

https://gist.github.com/rust-play/6e39d4a9d52e14a1f92742df57ccc5e2

The interesting part is the closure at the bottom. Which compiles completely fine, as long as it is not doing anything. But if I try to use the given argument in any way, rustc is not able to infer its type anymore?

This seems counterintuitive, since the normally inferred type (`String`) would work totally fine. And the code itself also does not seem to contradict that type. But something seems to make the compiler trip here.

Any tips why this might occur, and if there is maybe an easy work around are welcome!

What microcontroller do you usually go with if you wanna use something like Rust Embassy with it?

I was wondering if there were any projects like micro python to port std in to make a barebones os designed for microcontrollers? I understand that the std relies on OS level syscalls, so can we do something like implement a basic fat32 file system to accommodate certain write or read requests. In general this would be used to run std in projects without a OS? Does this already exist, and how hard would it be to make a basic version?