00:26 <re_irc> <9names (@9names:matrix.org)> adamgreig: Alternative timeline: you tack an arm core onto your PIC12F, and you're stuck supporting 2 lots of hardware and software forever

00:26 <re_irc> <adamgreig> all good options, right?

00:27 <re_irc> <adamgreig> s/forever/until 2038, when you make bank helping work around y2k38 problems and retire

00:30 <re_irc> <9names (@9names:matrix.org)> That, and hoping your lifetime buy of that 8051 (and supporting logic) that no-one manufactures any more lasts long enough

00:31 <re_irc> <dirbaio>

01:06 <re_irc> <James Munns> 9names: Oh hey, I worked at one of these companies

01:28 <re_irc> <adamgreig> modern day: you can't buy the PIC12 or the ARM, both have a lead time well into the next year

01:29 <re_irc> <adamgreig> I got a fun quote yesterday for some motors and drive units, lead time was 16 weeks on the motors which was worse than I was expecting, but there was a little † by the drive unit that had a footnote saying its lead time was ">52 weeks" 💀

01:29 <re_irc> <adamgreig> so this project in a month or two's time is already going well

01:29 <re_irc> <adamgreig> it has semiconductors in it, so I should have known!

01:29 <re_irc> <dirbaio> hopefully the incoming economic recession of doom causes people to buy less stuff so the shortages go away

01:30 <re_irc> <adamgreig>

01:31 <re_irc> <adamgreig> the other thing I buy a lot of at work is stainless steel and my gosh, you'd think it was alloyed with 5nm etched silicon wafers for the amount the price has gone up

01:31 <re_irc> <adamgreig> what a time to be buying things

01:32 <re_irc> <adamgreig> (stainless steel is made with nickel, much of which came from russia, so...)

01:32 <re_irc> <adamgreig> the nickel commodities price went up 400% in two days 💀 📈 📈

01:41 <cr1901_> Is this the reaping part of JIT inventory?

01:46 <re_irc> <adamgreig> it really is

01:57 <re_irc> <ian_rees> the supply chain issues are so interesting to me - here in New Zealand, we've got a few-months lead time on buying plaster board like used for wall linings in homes. AFAIK that's not a direct result of geopolitical stuff, chip shortages, etc. - it's more because demand wasn't there during our COVID lockdowns and the manufacturer now can't keep up

02:43 <cr1901_> Maybe all these companies need to download more RAM to increase the size of their JIT queues :)

03:00 <re_irc> <Lachlan> It looks like I’ll have to have to support the app jumping into the bootloader _and_ the bootloader jumping into the app, both without resetting the cpu

03:24 <re_irc> <Tom> sounds terrible

03:59 <re_irc> <Lachlan> Eh, I think it’ll be an interesting puzzle to get it working perfectly

04:00 <re_irc> <Lachlan> The hardware design was unfortunately not forward thinking in this particular area, so this is ultimately the only path

07:39 <re_irc> <henrikssn> Can I control alignment with the "cortex_m::singleton!" macro?

07:39 <re_irc> <henrikssn> I need the value to be 32-bit aligned

07:44 <re_irc> <henrikssn> "let buf: &mut [u8; BUF_SIZE] = unsafe { transmute(cortex_m::singleton!(: [u32; BUF_SIZE/4] = [0; BUF_SIZE/4]).unwrap()) };"

07:44 <re_irc> <henrikssn> I'm sure there is a better way but this will do for now...

07:45 <re_irc> <dirbaio> wrap it in your type, set "#[repr(align=4)]" on it

07:46 <re_irc> <dirbaio> * "#[repr(align(4))]"

07:46 <re_irc> <henrikssn> Something like "#[repr(align(4))] struct Buf([u8; BUF_SIZE])" ?

07:47 <re_irc> <dirbaio> yup

07:47 <re_irc> <henrikssn> cool thanks

09:22 <re_irc> <ryan-summers> Anyone got any tips on how to stop Rust/cargo from eating up harddrive space when you've got lots of various projects?

09:26 <re_irc> <9names (@9names:matrix.org)> I've seen some folks use a shared target dir, no idea how well that works when mixing in embedded projects.

09:26 <re_irc> my trick is to occasionally run this

09:26 <re_irc> # WARNING: Please don't run this unless you know what it's going to do.

09:26 <re_irc> find . -type d -name target -prune -exec rm -r {} \;

09:27 <re_irc> <ryan-summers> That's a very dangerous command right there, love it

09:27 <re_irc> <chrysn (@chrysn:matrix.org)> If you're going with find, you may just as well run "cargo clean" there. Less adrenaline, though.

09:27 <re_irc> <ryan-summers> Thanks for a good laugh in the morning :P

09:27 <re_irc> <9names (@9names:matrix.org)> yeah that would be _much_ safer :D

09:29 <re_irc> <ryan-summers> I think my root issue is that I'm running my drive at like 95% capacity all the time... Rust stuff is only like 10-20% of total space, which isn't unreasonable when that's a lot of my daily work

09:29 <re_irc> <9names (@9names:matrix.org)> it grows super fast

09:29 <re_irc> <ryan-summers> Yeah, it's still surprising to see ~30-60GB of data hanging around

09:30 <re_irc> <ryan-summers> Especially for source code / compiler tools

09:33 <re_irc> <burrbull> cargo cache

09:34 <re_irc> <ryan-summers> Ah that looks indeed very useful, thanks

10:34 <re_irc> <ub|k> am I the only one who gets mildly annoyed when i bump into code using "Debug" and then I'm using "heapless" with "ufmt" and I have to either rewrite the whole error chain code for "uDebug" or just ignore the nested errors?

10:35 <re_irc> <ub|k> any strategies to work around that?

13:54 <re_irc> <Lachlan> Same, but I use defmt

13:54 <re_irc> <Lachlan> There is a workaround there, though

14:04 <re_irc> <James Munns> Yeah, +1, I haven't used ufmt since defmt came around

14:34 <re_irc> <ub|k> ah, OK

14:34 <re_irc> <ub|k> Lachlan: what's that workaround?

14:37 <re_irc> <ub|k> and isn't defmt targeting a different use case? isn't it meant as a way to transmit logging data over the wire, rather than formatting strings e.g. to display on a screen?

14:37 <re_irc> <Lachlan> ‘defmt::Debug2Format(&x)’

14:39 <re_irc> <ryan-summers> Defmt is just a mechanism to defer formatting to the host side of things. Instead of the formatted string, it sends data + token information so the host can generate the formatted result

14:39 <re_irc> <ryan-summers> Which results in increased code size and bandwidth of the transmission mechanism

14:39 <re_irc> <ryan-summers> * decreased

14:39 <re_irc> <ub|k> yep, that's what I thought

14:39 <re_irc> <ryan-summers> +Also is generally faster on target

16:06 <re_irc> <James Munns> In general, when sending something over the wire, I also tend to use a binary format (like "postcard"), instead of formatting.

16:07 <re_irc> <James Munns> that being said, that STILL doesn't help you if you're printing it to a log or console directly.

21:30 <re_irc> <firefrommoonlight> Update on async eval quest. I'm actually sort of liking it for sending off 1000s of HTTP requests for a Desktop PC port scanner. Lets you do a bunch of concurrent IO bound tasks, which would be too many for OS threads

21:31 <re_irc> <firefrommoonlight> Important caveat that I don't know if it would still make sense if you're doing something that only has a handful of processes at a time. And I still dislike how it infects large parts of the code base, including replacing std lib functionality

21:31 <re_irc> <firefrommoonlight> *that last point is my main objection. It takes complete buy in

21:31 <re_irc> <firefrommoonlight> AFAIK

21:32 <re_irc> <dirbaio> in embedded, you're maybe going to do 2 things concurrently, not 1000

21:32 <re_irc> <dirbaio> but _you don't have threads at all_

21:32 <re_irc> <firefrommoonlight> That's why my experiments don't extend there!

21:32 <re_irc> <dirbaio> so without async you have to write these 2 things as state machines, which _suuucks_

21:33 <re_irc> <firefrommoonlight> Of note, I'm chatting with someone who's also writing Rust quadcopter firmware. He's using async; I'm curious how we'll approach similar problems with diff approaches

21:33 <re_irc> <firefrommoonlight> I'm using RTIC ISRs

21:33 <re_irc> <firefrommoonlight> He likes it so far

21:34 <re_irc> <firefrommoonlight> This is an interesting application for concurrency models, since it requires minimal latency with a number of concurrent processes occuring

21:34 <re_irc> <firefrommoonlight> Eg reading multiple sensors, accepting RF comm, sending signals to and receiving signals from motor controllers etc

21:34 <re_irc> <firefrommoonlight> I have already used all DMA1 streams lol

23:56 <re_irc> <Lachlan> Can’t wait for hals to add async support, going to change the game drastically

23:57 <re_irc> <Lachlan> Also, an async wrapper around smoltcp

23:57 <re_irc> <dirbaio> Lachlan: already exists :) https://github.com/embassy-rs/embassy/tree/master/embassy-net

23:58 <re_irc> <Lachlan> Ooo

23:59 <re_irc> <dirbaio> example https://github.com/embassy-rs/embassy/blob/net-refactor/examples/stm32h7/src/bin/eth.rs