ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
<re_irc> <9names (> adamgreig: Alternative timeline: you tack an arm core onto your PIC12F, and you're stuck supporting 2 lots of hardware and software forever
<re_irc> <adamgreig> all good options, right?
<re_irc> <adamgreig> s/forever/until 2038, when you make bank helping work around y2k38 problems and retire
<re_irc> <9names (> That, and hoping your lifetime buy of that 8051 (and supporting logic) that no-one manufactures any more lasts long enough
<re_irc> <dirbaio>
<re_irc> <James Munns> 9names: Oh hey, I worked at one of these companies
<re_irc> <adamgreig> modern day: you can't buy the PIC12 or the ARM, both have a lead time well into the next year
<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" ๐Ÿ’€
<re_irc> <adamgreig> so this project in a month or two's time is already going well
<re_irc> <adamgreig> it has semiconductors in it, so I should have known!
<re_irc> <dirbaio> hopefully the incoming economic recession of doom causes people to buy less stuff so the shortages go away
<re_irc> <adamgreig>
<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
<re_irc> <adamgreig> what a time to be buying things
<re_irc> <adamgreig> (stainless steel is made with nickel, much of which came from russia, so...)
<re_irc> <adamgreig> the nickel commodities price went up 400% in two days ๐Ÿ’€ ๐Ÿ“ˆ ๐Ÿ“ˆ
<cr1901_> Is this the reaping part of JIT inventory?
<re_irc> <adamgreig> it really is
explore has joined #rust-embedded
<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
starblue has quit [Ping timeout: 276 seconds]
starblue has joined #rust-embedded
<cr1901_> Maybe all these companies need to download more RAM to increase the size of their JIT queues :)
<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
emerent has quit [Ping timeout: 244 seconds]
emerent has joined #rust-embedded
<re_irc> <Tom> sounds terrible
<re_irc> <Lachlan> Eh, I think itโ€™ll be an interesting puzzle to get it working perfectly
<re_irc> <Lachlan> The hardware design was unfortunately not forward thinking in this particular area, so this is ultimately the only path
badboy has joined #rust-embedded
xnor_ has joined #rust-embedded
vancz_ has joined #rust-embedded
vancz has quit [*.net *.split]
badboy_ has quit [*.net *.split]
xnor has quit [*.net *.split]
lcbit has quit [*.net *.split]
lcbit has joined #rust-embedded
gsalazar has joined #rust-embedded
<re_irc> <henrikssn> Can I control alignment with the "cortex_m::singleton!" macro?
<re_irc> <henrikssn> I need the value to be 32-bit aligned
<re_irc> <henrikssn> "let buf: &mut [u8; BUF_SIZE] = unsafe { transmute(cortex_m::singleton!(: [u32; BUF_SIZE/4] = [0; BUF_SIZE/4]).unwrap()) };"
<re_irc> <henrikssn> I'm sure there is a better way but this will do for now...
<re_irc> <dirbaio> wrap it in your type, set "#[repr(align=4)]" on it
<re_irc> <dirbaio> * "#[repr(align(4))]"
<re_irc> <henrikssn> Something like "#[repr(align(4))] struct Buf([u8; BUF_SIZE])" ?
<re_irc> <dirbaio> yup
<re_irc> <henrikssn> cool thanks
nort has quit [Ping timeout: 260 seconds]
<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?
<re_irc> <9names (> I've seen some folks use a shared target dir, no idea how well that works when mixing in embedded projects.
<re_irc> my trick is to occasionally run this
<re_irc> # WARNING: Please don't run this unless you know what it's going to do.
<re_irc> find . -type d -name target -prune -exec rm -r {} \;
<re_irc> <ryan-summers> That's a very dangerous command right there, love it
<re_irc> <chrysn (> If you're going with find, you may just as well run "cargo clean" there. Less adrenaline, though.
<re_irc> <ryan-summers> Thanks for a good laugh in the morning :P
<re_irc> <9names (> yeah that would be _much_ safer :D
<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
<re_irc> <9names (> it grows super fast
<re_irc> <ryan-summers> Yeah, it's still surprising to see ~30-60GB of data hanging around
<re_irc> <ryan-summers> Especially for source code / compiler tools
dc740 has joined #rust-embedded
<re_irc> <burrbull> cargo cache
<re_irc> <ryan-summers> Ah that looks indeed very useful, thanks
dc740 has quit [Remote host closed the connection]
causal has joined #rust-embedded
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
<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?
<re_irc> <ub|k> any strategies to work around that?
balaa[m] has joined #rust-embedded
<re_irc> <Lachlan> Same, but I use defmt
<re_irc> <Lachlan> There is a workaround there, though
<re_irc> <James Munns> Yeah, +1, I haven't used ufmt since defmt came around
<re_irc> <ub|k> ah, OK
<re_irc> <ub|k> Lachlan: what's that workaround?
<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?
<re_irc> <Lachlan> โ€˜defmt::Debug2Format(&x)โ€™
<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
<re_irc> <ryan-summers> Which results in increased code size and bandwidth of the transmission mechanism
<re_irc> <ryan-summers> * decreased
<re_irc> <ub|k> yep, that's what I thought
<re_irc> <ryan-summers> +Also is generally faster on target
gsalazar has quit [Ping timeout: 248 seconds]
gsalazar has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
xnor_ is now known as xnor
<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.
<re_irc> <James Munns> that being said, that STILL doesn't help you if you're printing it to a log or console directly.
nort has joined #rust-embedded
gsalazar has quit [Ping timeout: 240 seconds]
dc740 has joined #rust-embedded
bjc has quit [Ping timeout: 240 seconds]
bjc has joined #rust-embedded
gsalazar has joined #rust-embedded
bjc has quit [Quit: ERC 5.4 (IRC client for GNU Emacs 28.1)]
bjc has joined #rust-embedded
gsalazar has quit [Ping timeout: 240 seconds]
hwj has joined #rust-embedded
gsalazar has joined #rust-embedded
bjc has quit [Remote host closed the connection]
bjc has joined #rust-embedded
aspe has joined #rust-embedded
aspe has quit [Quit: aspe]
aspe has joined #rust-embedded
aspe has quit [Client Quit]
aspe has joined #rust-embedded
aspe has quit [Client Quit]
aspe has joined #rust-embedded
aspe has quit [Quit: aspe]
bjc has quit [Remote host closed the connection]
bjc has joined #rust-embedded
hwj has quit [Remote host closed the connection]
dc740 has quit [Remote host closed the connection]
limpkin has quit [Quit: limpkin]
limpkin has joined #rust-embedded
limpkin has quit [Quit: limpkin]
limpkin has joined #rust-embedded
limpkin has quit [Quit: limpkin]
aspe has joined #rust-embedded
aspe has quit [Client Quit]
<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
<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
<re_irc> <firefrommoonlight> *that last point is my main objection. It takes complete buy in
<re_irc> <firefrommoonlight> AFAIK
<re_irc> <dirbaio> in embedded, you're maybe going to do 2 things concurrently, not 1000
<re_irc> <dirbaio> but _you don't have threads at all_
<re_irc> <firefrommoonlight> That's why my experiments don't extend there!
<re_irc> <dirbaio> so without async you have to write these 2 things as state machines, which _suuucks_
<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
<re_irc> <firefrommoonlight> I'm using RTIC ISRs
<re_irc> <firefrommoonlight> He likes it so far
<re_irc> <firefrommoonlight> This is an interesting application for concurrency models, since it requires minimal latency with a number of concurrent processes occuring
<re_irc> <firefrommoonlight> Eg reading multiple sensors, accepting RF comm, sending signals to and receiving signals from motor controllers etc
<re_irc> <firefrommoonlight> I have already used all DMA1 streams lol
limpkin has joined #rust-embedded
cr1901_ is now known as cr1901
<re_irc> <Lachlan> Canโ€™t wait for hals to add async support, going to change the game drastically
<re_irc> <Lachlan> Also, an async wrapper around smoltcp
<re_irc> <dirbaio> Lachlan: already exists :)
<re_irc> <Lachlan> Ooo