Creating a file system on the onboard flash for my ebook reader so that configs, fonts, and somebody's favorite books could be stored there instead of on the sd card.

At first I was using the embassy_rp::flash API but the flash has an unusual 4KiB writes, 4-256 byte reads and things where just getting a little complicated.

Then I realized I could use the linker to map the flash and let my FAT32/16/12 library work on the array. And the flash interactions are handled the same way that code is. Cut my code size for dealing with the flash from several hundred to a couple dozen(not counting the filesystem stuff). I am currently erasing it every time I update the firmware but that's a problem for future me.

Next I need to make the device show up as a usb hub with 1 or 2 mass storage devices. 1 for the on board flash and 1 for the sd card.
#embedded #no_std #rust

#rust #rustlang low-level and #no_std Devs: I have these memory registers which I can write to whenever needed.

Considering this is shared mutable static memory, does this violate aliasing rules in some way? It's impossible to cause memory unsafety because the content written is POD, no constructors, drops, etc.

I'm either copying/reading u8/u16 or C packed structs.

Ah i just roasted my sole #ESP32c6 board while measuring something with my voltmeter.
And almost no shop has a replacement in under 20 days.
I was so close prototyping the aquarium temperature regulator for my girlfriend.

#EmbeddedRust #Rust #no_std

It is my pleasure to announce that I'm leading an #embedded #Rust workshop at the #CCCamp23 . Come on Friday 17:00 to #Schattenland at #ChaosZone .

I'll show you how to use #no_std Rust, aka hard mode. Bring your laptop!

Wrote an implementation of thread local storage in #no_std #rust, for Linux x86_64, with options to a) use libc's thread local storage, b) leverage libc's thread local storage that something in the same process has set up, or c) work without native thread local storage at all.

Toying with the idea of publishing it as a crate but, uh, I guess these requirements are pretty niche.

I built a Rust crate to parse MacBinary and resource fork data. As a testbed I created a webpage that uses the crate compiled to WebAssembly to show the data contained within a file you select and allows you to download individual parts, all client-side.

Parsing is done without any heap allocations with makes it `no_std` (embedded) compatible too.

https://7bit.org/macbinary/

#RetroComputing #VintageMac #Rust #no_std

Exploring programming patterns can get tedious, when you're rewriting the same example for the third time, each version having different shortcomings.

It's useful to check the ground truth once in a while and see how the piece connects to the bigger system, but that's still more potentially wasted effort.

In totally unrelated news, coding #rust with #no_std is hard mode :)