ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
Amadiro__ has joined #rust-embedded
Amadiro_ has quit [Ping timeout: 240 seconds]
emerent has quit [Ping timeout: 258 seconds]
emerent has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
Shell has quit [Quit: ZNC 1.8.2 -]
Shell has joined #rust-embedded
aspe has quit [Quit: aspe]
tafa has quit [Ping timeout: 246 seconds]
tafa has joined #rust-embedded
dc740 has joined #rust-embedded
explore has joined #rust-embedded
dc740 has quit [Quit: Leaving]
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #rust-embedded
Amadiro has joined #rust-embedded
Amadiro__ has quit [Ping timeout: 272 seconds]
<re_irc> <manasiwibi> Hello
<re_irc> <manasiwibi> I'm trying to follow throught the Discovery book. It seems GDB isn't supported on Mac M1. Does LLDB can be used as an exchange?
<re_irc> <marmrt> I would try using probe-rs or probe-run instead of gdb
<re_irc> <marmrt> I have no experience with lldb, but I don't see why it wouldn't work
Amadiro_ has joined #rust-embedded
Amadiro has quit [Ping timeout: 240 seconds]
causal has quit [Quit: WeeChat 3.5]
<re_irc> <James Munns> I'm not sure if it's changed recently, but IIRC LLDB didn't have the ability to flash code, e.g. the "load" command
<re_irc> <James Munns> it might be possible now, or work-around-able by first flashing the device, but I can't recall seeing anyone do it.
Amadiro_ has quit [Ping timeout: 240 seconds]
<re_irc> <9names (> i'm pretty sure someone else in this channel resolved this by using the x86 toolchain via Rosetta
<re_irc> <9names (> *toolchain gdb
<re_irc> <manasiwibi> Thanks for references. Barely know about Rust and Microcontroller world, so it all seems unkown to me xd. I have fixed it now.
<re_irc> <manasiwibi> 9names: Yea I tried to install it via Rosetta but couldn't make the installation procces works. Turns out the GDB is already installed, I've just need to use the "arm-none-eabi-gdb .. " command. I believe it already installed from "brew install arm-none-eabi-gcc"
<re_irc> <newam> Is there a way to "format!" a string without jumping into the global alloc failed handler when OOM?
<re_irc> I know "heapless::String" can work around this, but I would prefer that this is heap allocated.
<re_irc> <newam> And the size is not known upfront, so I can't use try_reserve and "write!" without massive hacks.
<Lumpio-> If you make your own Write implementation it's not necessarily such a massive hack
<Lumpio-> Just wrap the String, call try_reserve in your own write_str and return an error if it fails (and then maybe arrange for a descriptive error to be returned even though fmt::Write doesn't allow that)
dc740 has joined #rust-embedded
dc740 has quit [Client Quit]
aspe has joined #rust-embedded
aspe has quit [Quit: aspe]
<re_irc> <adamgreig> hi room, meeting time again! agenda is, please add anything you'd like to announce or discuss and we'll start in ~5 minutes
<re_irc> <adamgreig> fairly quiet week! i've been at emf camp since thursday morning and only back yesterday evening, though i did have a few occasions to spread the good word about rust :P
<cr1901> Quiet can be good sometimes.
<cr1901> Means things are working smoothly maybe :P
<re_irc> <therealprof> Yeah, after manic months...
<re_irc> <adamgreig> ok, well let's start and see where we get to, I don't have any announcements for this week
<re_irc> <therealprof> Has anyone tried the latest nightly by any chance?
<re_irc> <adamgreig> we released cortex-m 0.7.5 last week with inline-asm feature available on stable, no complaints about it so far
<re_irc> <adamgreig> nope, anything up?
<re_irc> <adamgreig> interesting, does that only affect forbid(unsafe_code)?
<re_irc> <therealprof> That's my understanding. They've done a crater run but I wouldn't expect too many link sections to appear in regular code.
<re_irc> <adamgreig> probably not uncommon for embedded applications to have both forbid(unsafe_code) and link_section
<re_irc> <therealprof> That's what I was thinking, though I only vaguely remember some no_std libaries using forbid(unsafe_code).
<re_irc> <adamgreig> libraries don't tend to use link_section, though
<re_irc> <adamgreig> I just had a quick check and indeed the lint only shows if you have forbid(unsafe_code)
<re_irc> <therealprof> Right.
<re_irc> <dirbaio> I guess you can "allow(unsafe_code)" just the fn with link_section
<re_irc> <dirbaio> or its parent mod
<re_irc> <adamgreig> yea, that works
<cr1901> I do allow(unsafe_code) with a comment personally
<re_irc> <adamgreig> so I guess the worst thing is it might be a breaking change for some applications, but probably not for (m)any libraries
<re_irc> <therealprof> Lots of interesting changes in the Rust compiler lately.
<re_irc> <therealprof> Many huge performance improvements but also some disruption potential.
<re_irc> <adamgreig> hopefully stabilising naked functions gets unstuck soon too
<re_irc> <adamgreig> the only other thing from the agenda I wanted to briefly mention is this question about whether embedded-hal's CAN error enum should include the Acknowledge error since drivers won't generally be able to return it,
<re_irc> <adamgreig> it's possible some driver implements some method to return error status on previous enqueued frames and then the variant could be useful, and having it means we cover all the bases of the official documented types of can mac error, so there's probably no compelling reason to remove it, but maybe the docs should mention this?
<cr1901> I say keep it just in case- You Are Gonna Need It
<re_irc> <adamgreig> well, that's all I had for this week, if anyone wants to mention anything else please go for it, otherwise we can wrap up here
<re_irc> <therealprof> I got nothing... still catching up... 😅
mattgirv_ has joined #rust-embedded
mattgirv has quit [Ping timeout: 248 seconds]
mrkajetanp has quit [Ping timeout: 248 seconds]
mrkajetanp_ has joined #rust-embedded
vancz_ has quit []
vancz has joined #rust-embedded
dc740 has joined #rust-embedded
<re_irc> <firefrommoonlight> When is the next planned stm32 PAC release? It would be nice to have the G0 fixes etc. Last was in October
<re_irc> <firefrommoonlight> I understand these are tricky since they're breaking
aspe has joined #rust-embedded
<re_irc> <jacobrosenthal> wonder if these hooks are generalized
explore has quit [Quit: Connection closed for inactivity]
aspe has quit [Quit: aspe]
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded