#no_std — Public Fediverse posts

I hate #async in #Rust.
I say that after writing 4 toy runtimes for it.

I have a very async-shaped problem and I *still* can't use async for it without ugly hacks.

Lifetime hell is trying to kill me. Will self-referential struct save me or finish the job? Let's find out.

Yeah, I'm riding #no_std , no alloc, why do you ask?

#programming #rustlang #unsafe #jazda

I hate #async in #Rust.
I say that after writing 4 toy runtimes for it.

I have a very async-shaped problem and I *still* can't use async for it without ugly hacks.

Lifetime hell is trying to kill me. Will self-referential struct save me or finish the job? Let's find out.

Yeah, I'm riding #no_std , no alloc, why do you ask?

#programming #rustlang #unsafe #jazda

I hate #async in #Rust.
I say that after writing 4 toy runtimes for it.

I have a very async-shaped problem and I *still* can't use async for it without ugly hacks.

Lifetime hell is trying to kill me. Will self-referential struct save me or finish the job? Let's find out.

Yeah, I'm riding #no_std , no alloc, why do you ask?

#programming #rustlang #unsafe #jazda

I hate #async in #Rust.
I say that after writing 4 toy runtimes for it.

I have a very async-shaped problem and I *still* can't use async for it without ugly hacks.

Lifetime hell is trying to kill me. Will self-referential struct save me or finish the job? Let's find out.

Yeah, I'm riding #no_std , no alloc, why do you ask?

#programming #rustlang #unsafe #jazda

I hate #async in #Rust.
I say that after writing 4 toy runtimes for it.

I have a very async-shaped problem and I *still* can't use async for it without ugly hacks.

Lifetime hell is trying to kill me. Will self-referential struct save me or finish the job? Let's find out.

Yeah, I'm riding #no_std , no alloc, why do you ask?

#programming #rustlang #unsafe #jazda

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

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

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

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

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

if you don't want the dependencies, go #![no_std]: doc.rust-lang.org/core/ without it, you're explicitly opting into system dependencies for maximum ease of use...

core - Rust

#![no_std] -> #![stdlib(core)], #![stdlib(alloc)], implicit #![stdlib(std)] i haaaate relying on compile testing to check for alloc usage in a scope. sooo annoying. would rather it be denied like std.

🦀 atomic_enum: An attribute to create an atomic wrapper around a C-style enum - can be used in #[no_std] environments - Internally, uses AtomicUsize to store the value - The atomic operations have the same semantics as the equivalent operations of AtomicUsize crates.io/crates/atomi... #rustlang

🦀 atomic_enum: An attribute to create an atomic wrapper around a C-style enum - can be used in #[no_std] environments - Internally, uses AtomicUsize to store the value - The atomic operations have the same semantics as the equivalent operations of AtomicUsize crates.io/crates/atomi... #rustlang

🦀 atomic_enum: An attribute to create an atomic wrapper around a C-style enum - can be used in #[no_std] environments - Internally, uses AtomicUsize to store the value - The atomic operations have the same semantics as the equivalent operations of AtomicUsize crates.io/crates/atomi... #rustlang

🦀 atomic_enum: An attribute to create an atomic wrapper around a C-style enum - can be used in #[no_std] environments - Internally, uses AtomicUsize to store the value - The atomic operations have the same semantics as the equivalent operations of AtomicUsize crates.io/crates/atomi... #rustlang

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

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

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

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

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!

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!

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!

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!

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!

So we're gradually rewriting it in #no_std #rust. We can make direct syscalls, which are allowed by our seccomp filter so as to avoid recursion, and that's about it.

Luckily most of what this library does is set up fast IPC to our main process and delegate most of the syscall handling to there, so there's not that much we need to implement in this constrained environment. It's certainly making for some interesting exercises, though.

So we're gradually rewriting it in #no_std #rust. We can make direct syscalls, which are allowed by our seccomp filter so as to avoid recursion, and that's about it.

Luckily most of what this library does is set up fast IPC to our main process and delegate most of the syscall handling to there, so there's not that much we need to implement in this constrained environment. It's certainly making for some interesting exercises, though.

So we're gradually rewriting it in #no_std #rust. We can make direct syscalls, which are allowed by our seccomp filter so as to avoid recursion, and that's about it.

Luckily most of what this library does is set up fast IPC to our main process and delegate most of the syscall handling to there, so there's not that much we need to implement in this constrained environment. It's certainly making for some interesting exercises, though.

So we're gradually rewriting it in #no_std #rust. We can make direct syscalls, which are allowed by our seccomp filter so as to avoid recursion, and that's about it.

Luckily most of what this library does is set up fast IPC to our main process and delegate most of the syscall handling to there, so there's not that much we need to implement in this constrained environment. It's certainly making for some interesting exercises, though.

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.

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.

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.

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

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

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

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

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 :)

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 :)

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 :)

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 :)

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 :)

Because the crate I made yesterday (https://crates.io/crates/microasync) didn't have much to offer except for the sync function and yet got so much positive feedback, I thought I'd make another *very small* #rust crate to provide a more proper #async #runtime and IO.

This entire crate and its one dependency together are smaller than the futures-executor crate, while having more features. It's also got #no_std support (only for the runtime, not the IO)!

https://crates.io/crates/microasync-util

#rustlang

Because the crate I made yesterday (https://crates.io/crates/microasync) didn't have much to offer except for the sync function and yet got so much positive feedback, I thought I'd make another *very small* #rust crate to provide a more proper #async #runtime and IO.

This entire crate and its one dependency together are smaller than the futures-executor crate, while having more features. It's also got #no_std support (only for the runtime, not the IO)!

https://crates.io/crates/microasync-util

#rustlang

Because the crate I made yesterday (https://crates.io/crates/microasync) didn't have much to offer except for the sync function and yet got so much positive feedback, I thought I'd make another *very small* #rust crate to provide a more proper #async #runtime and IO.

This entire crate and its one dependency together are smaller than the futures-executor crate, while having more features. It's also got #no_std support (only for the runtime, not the IO)!

https://crates.io/crates/microasync-util

#rustlang

Because the crate I made yesterday (https://crates.io/crates/microasync) didn't have much to offer except for the sync function and yet got so much positive feedback, I thought I'd make another *very small* #rust crate to provide a more proper #async #runtime and IO.

This entire crate and its one dependency together are smaller than the futures-executor crate, while having more features. It's also got #no_std support (only for the runtime, not the IO)!

https://crates.io/crates/microasync-util

#rustlang

pc-beeper

The most primitive audio device available on PC-compatible systems with characteristic "beeps" and "squeaks"

https://github.com/deadblackclover/pc-beeper

#rust #os #no_std #pc_speaker