James Munns
@jamesmunns.com
5.4K followers 750 following 6.7K posts
Notable Protocol Enjoyer. Doing stuff, mostly in Rust and on Embedded systems. Need help with that? Hire me @onevariable.com Co-host @sdr-podcast.com DMs (matrix): @jamesmunns:beeper.com DMs (signal): jamesmunns.255 he/him Kein Ort für Nazis
Posts Media Videos Starter Packs
Yeah, the turbofish I pass here is a marker trait impl that has associated Request and Response types (and some other precomputed const stuff), so when you call functions like `serve` or `request`, it can figure out the argument + return types automatically (and pre-populates headers w/ metadata)
Yeah, tbf, *I* think this is very clear, but I also like doing sicko stuff, especially with turbofished methods that take bundled traits like the Endpoint here :D

You can also write much less noisy Rust in most cases, for sure.
A screenshot of a slide with the following rust code:

let socket = STACK.endpoints()
.bounded_server::<PwmSetEndpoint, 2>(Some(name));
let socket = pin!(socket);
let mut hdl = socket.attach();
loop {
let
_
= hdl.serve_blocking(|data: &f32| -> u64 {
let val = data.clamp(0.0, 1.0);
let val = val * const { u16::MAX as f32 };
let val = val as u16;
pwm.set_duty_cycle(val);
Instant::now().as_ticks()
})
.await;
}
Evergreen post
rust! it's a good language
I probably should finally shell out to get a tag-connect cable or two though.
Cool! Where do I plug the other end into my RP2040 pico that I'm using as my debugprobe? :D

(I do have a real j-link with the nice 2x5 0.05" connector I use, but it's nice to be able to throw a $5 dev board at a project and have a "semi-permanent" debugger dedicated to it for quick switching)
But 2.54mm pin headers means I can attach wire wraps to it easier!
Reposted by James Munns
RIP to a king, your family has kept it going
L.C. Richardson, an older black man, is sitting on a folding outdoor chair, holding up a photo (coaster?) with a photo of the LC's Bar-B-Q sign. He is wearing a KC Chiefs hat and is carrying a jovial belly and smile of a man who has been cooking and eating barbecue for the better part of his life. Tausha Hammett, granddaughter of LC, smiling and sitting at a table in his restaurant (now hers) with his old office nameplate on it. Behind is a smiling photo of Richardson.
Reposted by James Munns
PSA: I made a separate channel to post twitch VODs — here's the test quiz I ran with Luuk before EuroRust: www.youtube.com/watch?v=3nz8...
I test your Rust, you test my quiz (ft. ThouCheese)
YouTube video by fasterthanlime VODs
www.youtube.com
If you take photos of your B roll camera, does that mean this is c-roll footage?
Reposted by James Munns
The internet died in the ‘50s.
I mean people have been using Time Switches since the '50s to turn their home lights on and off so people can't tell they aren't at home so they don't get burgled:

en.wikipedia.org/wiki/Time_sw...

It's just a question of how far you're broadcasting your side channel info 🙃
Time switch - Wikipedia
en.wikipedia.org
Posting daily high/lows, daily averages, or weekly/monthly averages is much less revealing. But even delayed historical data shows trends.

Even averages can show things like "we weren't home that day much" or "we were clearly on vacation for these days".

It's a bummer, but imo: keep it private.
Yeah, honestly, probably don't. Up to you to decide your threat model/risk tolerance, but if you wouldn't post "hey these are all the times I/my family is home" on the internet, I wouldn't post a livestream of sensor data like that.

It's all sidechannel information leaking.
fwiw: be careful with making data from sensors like this in your home public. They (particularly temperature, co2, and humidity) are *extremely* good indirect indicators of facts like "when you are home", when you are in a room, etc.

The ABSOLUTE numbers are whatever, trends are VERY revealing.
Reposted by James Munns
We're excited to announce a new initiative to support the Rust Project, our Rust Maintainers Fund!

We are setting out to employ 6 full-time maintainers and 6 interns in 2026 to make sure #rustlang is well maintained and bugs and contributions get the attention they need.

Read more: rustnl.org/fund
RustNL - Rust Maintainers Fund - Keeping the Rust Project maintained so you can focus on building reliable software
Reposted by James Munns
I'm excited to share what I've been working on with @erikjee.bsky.social: RustNL's #rustlang Maintainers Fund!

Many people and companies contributing to Rust, but there are fewer and fewer paid positions for general maintenance (reviews,cleanups,etc). We need to fix that.

bsky.app/profile/rust...
We're excited to announce a new initiative to support the Rust Project, our Rust Maintainers Fund!

We are setting out to employ 6 full-time maintainers and 6 interns in 2026 to make sure #rustlang is well maintained and bugs and contributions get the attention they need.

Read more: rustnl.org/fund
RustNL - Rust Maintainers Fund - Keeping the Rust Project maintained so you can focus on building reliable software
Ooh, that's true, I do think they do mention errata inline, they definitely deserve credit for that!
like, if you FIND an errata, you should ALSO update your reference manual/datasheet with a big "INOP" sticker, or at least a warning like "THERE ARE SIGNIFICANT ISSUES WITH THIS".

I don't get how they keep shipping known-wrong reference manuals/datasheets, that get other updates.
I have stones to throw at all the major vendors, honestly, it's not specifically NXP and STMicro. Even Nordic, who is usually really great, doesn't put warnings in their main datasheet for things like "hey actually this whole functionality doesn't work" (like XIP via QSPI on the nrf52 family)
at least shout out to NXP for putting that note IN the same document (where they show you in like 4 other places how to use it), unlike STMicro that just has a totally separate errata doc that says "oh lol that doesn't work at all", and they never update the datasheet at all.
Embedded development is great because you'll have a datasheet that has multiple diagrams and sections about the wonderful PLLs, and how you can use them to flexibly divide your clock sources, wow, they are so great, here's how to use them, and then have one little "Note" that says "don't use this".
A screenshot of a datasheet describing a PLL clock divider, but the datasheet also has a note that says:

this clock divider must be set to divide by 1 (DIV = 0). All of the places that main_pll_clk goes have additional downstream dividers (SYSCPUAHBCLKDIV and DSPCPUCLKDIV for example) that can lower the rate locally if desired.
Do you need to explicitly rebuild `core` (and maybe alloc) with your sanitizer settings as well? e.g. `build-std test,core,alloc`?

I can't remember if just specifying `test` also rebuilds all deps.

Having the hint recommend something you're already doing definitely seems wrong tho.
It's from the late 70s, so for some things, there's a world where you could feasibly have used discrete logic (instead of CPUs) to display things, and being able to send BCD means a lot less transistors/logic!
A thing to remember is that some avionics (and their standards) are OLD. In some cases, it was just much easier to send BCD to allow for simpler displays and such.