norineko has quit [Remote host closed the connection]
norineko has joined #rust-embedded
tamme[m] has joined #rust-embedded
<tamme[m]>
<therustybits[m]> "Yeah, that certainly wasn't..." <- I wonder if it was possible to use something like VS Code LiveShare to record the video on an editor that is not used for typing
JamesSizeland[m] has joined #rust-embedded
<JamesSizeland[m]>
<therustybits[m]> "That's great to hear, thanks for..." <- I love your vids, we share them around at work as soon as they drop too!
K900 has joined #rust-embedded
<K900>
I feel like someone must have done something like this already
<K900>
I have a Pi Pico here that I want to use a remote debug probe of sorts
<Darius>
K900: probe-rs?
<K900>
As in connect it to a device in a definitely-not-reachable-with-a-computer location and then poke it over the network
<Darius>
well, rusty-probe
<K900>
That's USB
marmrt[m] has joined #rust-embedded
<marmrt[m]>
I have done some long distance debugging using port forwarding. I got it working once but it was finicky enough that I ended up just ssh-ing into the remote machine and doing things locally there
<ithinuel[m]>
Hey there, I received a mail flagged as suspicious from `secureserver@teams.rust-embedded.org`.
<ithinuel[m]>
I don’t think it’s a genuine one as I don’t remember any account with that domain.
<ithinuel[m]>
Something about a password expiration but with an attachment.
<JamesMunns[m]>
<ithinuel[m]> "Hey there, I received a mail..." <- Cc @Nick Stevens
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
Almost certainly spam, probably spoofing the source address, was it sent to one of the teams email addresses?
cinemaSundays has joined #rust-embedded
<JamesMunns[m]>
Misc note, opened https://github.com/rust-embedded/wg/issues/792 to discuss "what if we don't make targets for all of the risc-v extensions and v8m profiles", it came up regarding ABI flags and other situations where you need/want the stdlib to match the compilation options of your binary. Added it to the agenda for today.
<JamesMunns[m]>
thejpster if you have a second, I know you recently looked into all the different v8m profiles and options, is that somewhere I can link to in this issue for reference?
mrkajetanp has joined #rust-embedded
anton_star has quit [Quit: Client closed]
mrkajetanp has quit [Ping timeout: 246 seconds]
dav1d has quit [Ping timeout: 252 seconds]
dav1d has joined #rust-embedded
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 246 seconds]
cinemaSundays has quit [Quit: Connection closed for inactivity]
aliceryhl[m] has joined #rust-embedded
<aliceryhl[m]>
Since this issue is also really relevant to my interests in Rust for Linux, it would be great if we would collaborate on a way to move forward with these ABI-relevant flags.
tiwalun[m] has joined #rust-embedded
<tiwalun[m]>
Has anybody used a RISC-V RV32E chip recently? I’m trying to loosely follow https://noxim.xyz/blog/rust-ch32v003/introduction/, but I’m stuck with a linker error:`` cannot link object files with different EF_RISCV_RVE ``
<tiwalun[m]>
I'm using nightly, with build-std. I've looked at the object / rlib files, and they seem mostly correct. The `` lib.rmeta `` parts have different flags, not sure if that is a problem .
<M9names[m]>
just tested building blinky from there with 1.82.0-nightly, linked fine
<thejpster[m]1>
<JamesMunns[m]> "thejpster if you have a second..." <- It all went into the target docs
<thejpster[m]1>
Use of MVE is an interior option. PAC BTI might be an exterior option but you can ignore it because no one uses it.
<thejpster[m]1>
DSP and SIMD are interior options.
<M9names[m]>
<M9names[m]> "> <@tiwalun:matrix.org> Has..." <- > <@9names:matrix.org> are you following that guide for fun? you don't really need to build a custom rustc for rv32e any more, much easier to go with what's available at
<M9names[m]>
there's also the newer hal at https://github.com/ch32-rs/ch32-hal that also works, i haven't spent much time with it beyond running a blinky but it's where the current development is happening.
<tiwalun[m]>
<M9names[m]> "> <@tiwalun:matrix.org> Has..." <- > <@9names:matrix.org> are you following that guide for fun? you don't really need to build a custom rustc for rv32e any more, much easier to go with what's available at
<tiwalun[m]>
I’m not doing the custom LLVM part, sorry for being unclear. Just used the guide to try and figure out the necessary target features. I'll check out the repo, thanks for the link.
<thejpster[m]1>
FWIW I have no trouble running thumbv6-none-eabi binaries on a thumbv8m.main-none-eabihf OS, because none of my boundary functions use floats and EABI is just EABI regardless of Arm architecture version.
<thejpster[m]1>
The reason you want to rebuild libstd with MVE is not for compatibility, but because you want the Unicode text functions to get that sweet sweet vectorisation.
<M9names[m]>
thejpster[m]1: it's when you're linking against other people's binaries that it all falls apart
<JamesMunns[m]>
Yeah, the initial issue was a case where core/std use hardfloat, but the application uses softfloat, which is an ABI problem
<thejpster[m]1>
We should be clearer about ABI vs use of FPU. cortex-m-rt annoyingly mixes them up and only enables the FPU on hard float targets.
<thejpster[m]1>
Or “interior and exterior features” as I’m going to call them
<thejpster[m]1>
Usefully any single precision FPU on Arm can be used to hold double precision values, so there’s only one ABI for hard float, even if your passing f64 values that the FPU can’t process.
<thejpster[m]1>
s/your/you’re/
<tiwalun[m]>
<M9names[m]> "> <@9names:matrix.org> are you..." <- I was missing the llvm-abiname entry in my target json file, now I'm getting further, thanks! I'm using a different chip, so I can't use half unfortunately.
<JamesMunns[m]>
(if you could put this all on the discussion issue, that would be very helpful)
<M9names[m]>
tiwalun[m]: oh, which one are you using?
<tiwalun[m]>
<M9names[m]> "nice" <- Now I'm missing symbols for critical section. Any idea why this could be? I should have the correct features and crates for it, it worked when I was compiling for r32i.
mrkajetanp has quit [Ping timeout: 260 seconds]
<M9names[m]>
no clue, should work AFAIK
mrkajetanp has joined #rust-embedded
<tiwalun[m]>
Figured it out, adding use riscv as _; helped, wasn't necessary before for some reason.
<M9names[m]>
ah, cool! are you running code on it yet or just getting set up?
<tiwalun[m]>
Trying to run code, but something is still wrong. At least compilation works.
matoushybl[m] has joined #rust-embedded
<matoushybl[m]>
Hi, not sure if anyone here uses ROS, but I have done some work on making microROS available from Rust (currently embassy is used as a runtime). The work is in early stages with a lot of rough edges, but seems to work for my use case right now. https://github.com/matoushybl/microros-rs
<JamesMunns[m]>
@thejpster when would you want to do this?
<JamesMunns[m]>
> If you use a soft-float target but add a target option to enable the FPU (which is entirely valid)
<dirbaio[m]>
if for some reason you need to link to soft-float abi code
<dirbaio[m]>
like, a binary blob
<dirbaio[m]>
or you made some OS where people install "apps" that link against your OS, and your first product had no FPU and later you upgrade to have an FPU and don't want to break people's apps
<JamesMunns[m]>
hmm, yeah I guess you could use the softfloat abi but with hardfloat ops? but whew I've never seen that in the wild before :D
<dirbaio[m]>
yea, feels like super niche
<JamesMunns[m]>
I also have very little faith that would like... work, consistently, and not cause miscompilations, but maybe JP has seen some more crazy stuff in his career than I have :D
<thejpster[m]1>
cough proprietary pre-compiled C libraries are thare only soft-float cough
<thejpster[m]1>
* cough proprietary pre-compiled C libraries that are only soft-float cough
<JamesMunns[m]>
:D
<JamesMunns[m]>
I figured
<thejpster[m]1>
--target=thumbv7em-none-eabi -Ctarget-cpu=cortex-m4 will also do this
<dirbaio[m]>
Was this the thing where llvm assumes all optional things are present by default?
<thejpster[m]1>
cortex-m4f is not a valid target-cpu
<dirbaio[m]>
Confusing :D
AtleoS has quit [Ping timeout: 248 seconds]
joelsa[m] has joined #rust-embedded
<joelsa[m]>
Hey everybody, juliand and I are having a casual and open "Rust Embedded chat" where anyone can join and discuss current projects and challenges using embedded Rust from now until 18:00 CEST. https://meet.google.com/cbj-tumu-bmg
<JamesMunns[m]>
first - project director elections are coming up soon. Project Directors sit on the Rust Foundation board, representing the Rust Project
<JamesMunns[m]>
members of the project can nominate potential directors, and the council will elect the directors out of the nominated parties. This go around, two seats are available
<JamesMunns[m]>
there is an "RSVP" google form on that post - if you are an embedded-wg member, you can respond there (it asks for your affiliation, you can say "Embedded Working Group")
<JamesMunns[m]>
Please do fill out the RSVP if you think you'll go, so they can get accurate head counts and plan for space to reserve for us.
<JamesMunns[m]>
This is also very important if you require an official invitation, either for visa purposes, or for your work to allow you the time off to go (or for them to pay for your travel, etc.)
<JamesMunns[m]>
(RustNL will be able to issue formal invitations, which are required by some folks for visas - general rules for the Netherlands apply!)
<JamesMunns[m]>
if you have any questions for either of those, lemme know! Happy to chat here or DM. Otherwise, that's all the official announcements I have (I do have one other topic tho :) )
<adamgreig[m]>
thank you! any other announcements from anyone?
<adamgreig[m]>
oh, me, actually; I can run next week's meeting but after that I'll be away for 3 weeks and not in a timezone conducive to this meeting time
<adamgreig[m]>
if anyone would like to help run the meeting (or try an anarchistic free for all) please consider and we can discuss next week
<adamgreig[m]>
(so that's the 17th, 24th sept and 1st oct I'll be away)
<JamesMunns[m]>
oh, I will likely not be available for the next two meetings due to travel to/from RustConf
<JamesMunns[m]>
Also, I'll be at RustConf, let me know if anyone else will be there and want to meet up :)
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
I'll be at RustConf. Probably can't make next week's meeting.
<JamesMunns[m]>
I can help out the 24th and 1st of oct
<bartmassey[m]>
Someone more qualified should volunteer, but if not I can do the 17th.
<adamgreig[m]>
cool, thanks! let's see how it goes next week then
<adamgreig[m]>
I'll prepare the agenda discussion pages in advance perhaps so it's mostly just a case of guiding discussions :)
<adamgreig[m]>
also my plane isn't due to take off until 20 minutes into the meeting slot on the 17th :P
<adamgreig[m]>
ok, James Munns want to go ahead with your point about build-std?
<JamesMunns[m]>
It came up that Rust has a -C soft-float option or something like that, and that has fun implications because that actually makes your code use a different ABI than the standard library
<adamgreig[m]>
oh lmao of course
<adamgreig[m]>
in C land doesn't a different pre-built std lib get linked depending on float abi among other things?
<JamesMunns[m]>
We had talked a bit about "how do we customize targets soundly", particularly around risc-v (with lots of extensions) and armv8m which also has a lot of optional features
<JamesMunns[m]>
adamgreig[m]: dunno, offhand! I can find the upstream issue in a bit
<JamesMunns[m]>
I made a tracking issue as aliceryhl and the Rust for Linux folks have potentially overlapping needs here
Foxyloxy has joined #rust-embedded
andar1an[m]1 has joined #rust-embedded
<andar1an[m]1>
<JamesMunns[m]> "Also, I'll be at RustConf, let..." <- I will be and would love to meet people from embedded!
<JamesMunns[m]>
so, it might make sense to do some discussion here on what we need, and how we might want it, to propose changes or stabilization to rustc or cargo to maybe kill two birds with one stone:
<JamesMunns[m]>
* Handle ABI-relevant "must recompile" features, called "exterior features" by JP
<JamesMunns[m]>
* Handle "nice to have" perf features, like double precision FPU, called "interior features" by JP
<JamesMunns[m]>
(like wanting the stdlib to be recompiled knowing you have a double precision FPU instead of a default single precision FPU)
<JamesMunns[m]>
This came up in some idle discussions AFAIR at RustNL, so I wanted to get it in writing so we could share thoughts, and probably discuss in more detail in a future meeting.
Foxyloxy__ has joined #rust-embedded
<aliceryhl[m]>
We also discussed it at RustNL in the Rust language group.
<aliceryhl[m]>
Well, not in very much detail, but ... it did come up briefly
<adamgreig[m]>
is this both "stabilise some form of build-std" and "extend cargo to detect when std needs to be rebuilt anyway due to features"?
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
afaiu, for risc-v targets you can already pass args to rustc via compiler options for extensions
<adamgreig[m]>
rmsyn[m]: yea, you can pass args, but that won't cause libcore to be rebuilt using them
Foxyloxy_ has quit [Ping timeout: 252 seconds]
<JamesMunns[m]>
and ideally, in a way that is possible to stabilize, if we decide this is preferrable for cases like risc-v instead of making 128 different targets with different extensions
<aliceryhl[m]>
The big thing I keep getting pushback on is "what if you mix together code compiled with and without the flag / target modification"
<JamesMunns[m]>
adamgreig[m]: maaaaybe a stabilized subset? Not sure I want to prescribe the "how" yet, but eventually we'll need to.
<aliceryhl[m]>
In the case of the kernel, we don't use Cargo or std, so we can just build core normally without -Zbuild-std.
Foxyloxy has quit [Ping timeout: 248 seconds]
<rmsyn[m]>
JamesMunns[m]: this seems like it would blow up rather quickly, especially with all possible combinations, future extensions, etc.
<JamesMunns[m]>
aliceryhl[m]: yeah, I think there are cases where it's fine but suboptimal, and some cases like FPU ABI where it is fully unsound
<JamesMunns[m]>
aliceryhl[m]: Ah, I hadn't thought about RfL not using cargo, which is currently where the build-std machinery all lives
<aliceryhl[m]>
afaik only std needs weird stuff in the build, maybe we could stabilize -Zbuild-std or similar only in the no-std case
<JamesMunns[m]>
aliceryhl[m]: yeah, that's part of what was discussed, tho there's probably some discussion to be had around "what configuration options are stabilized then"
<rmsyn[m]>
aliceryhl[m]: what about when something like vector extensions (features) are used, and core could take advantage? is that what you mean by stabilizing?
<adamgreig[m]>
aliceryhl[m]: so what's the change for you? i thought the idea was around cargo detecting that a rebuild needs to happen, if you're building your own core anyway can't you already just build it with the right features?
<jannic[m]>
Is that sufficient? For example the RISC-V esp32 chips are often used with std, AFAIK. So at least some embedded applications need std.
<JamesMunns[m]>
(like, maybe just target-features, but there are other things like panic-immediately-abort or optimize-for-size that they might not want to stabilize)
Foxyloxy has joined #rust-embedded
<JamesMunns[m]>
adamgreig[m]: I think there are some rustc flags that are not necessarily target-features?
<JamesMunns[m]>
(Alice would know better tho)
<aliceryhl[m]>
adamgreig[m]: We have a bunch of things that can only be enabled using target features, but they're unknown and only work because they're passed straight to LLVM, but this emits a warning which we don't want. Trying to stabilize them as a target feature doesn't work because they affect ABI. Trying to add them as a flag also runs into issues because `-C` flags aren't supposed to be able to cause UB.
<adamgreig[m]>
aah yea, I see
<adamgreig[m]>
aren't "supposed" 😬
<andar1an[m]1>
Does the standard library and the related cargo work and mentioned ABI relate to a specific kernel?
<aliceryhl[m]>
Right now x86 uses target.json in te kernel because of this issue.
<JamesMunns[m]>
in this discussion, it might make sense to describe some kind of configuration that is not target-features, that can be passed to rustc, and used by cargo to determine if the features match the precompiled stdlib
<andar1an[m]1>
I thought the standard library required and underlying operating system, I may not haveearned correctly. I just thought for baremetal embedded work, one used no-std, so trying to understand. I can ask this later. Not important now
<JamesMunns[m]>
for rustc, it might just bail if the configuration doesn't match or something.
<JamesMunns[m]>
For cargo, it could trigger a source build of the stdlib
<JamesMunns[m]>
andar1an[m]1: We're using "stdlib" loosely to mean `core` and/or `alloc` and/or `std` here.
<JamesMunns[m]>
(or some other way of solving this, but that's what came to mind for me :) )
<adamgreig[m]>
so target-features would remain for things that don't change the ABI, and the target name remains for whole big ABIs that set lots of LLVM things, but we can maybe contain some of the target explosion by this third new thing?
<JamesMunns[m]>
adamgreig[m]: That's vaguely the problem domain and potential solutions, yeah :D
<aliceryhl[m]>
So what I'm imagining is some sort of Cglobal-target-feature or Ctarget-modifier or whatever that lets you pass ABI modifying flags. We make it sound by ensuring that the flags of a crate match exactly what was passed to its deps. So through core everything is forced to pass the same flags. Tada, no UB possible. Then maybe we add a Cbuild-core-alloc or similar that is like Zbuild-std but can be stabilized (hopefully !!)
<andar1an[m]1>
Ah okay, so like iterators but not threads for e.g?
<andar1an[m]1>
Or basically a subset of standard library features that don't require underlying OS?
<andar1an[m]1>
Wish there was a different word as a n00b haha
<JamesMunns[m]>
JamesMunns[m]: It's also possible that this ends up replacing target-features for some common use cases, like riscv extensions or armv8m options
<adamgreig[m]>
there are other ABI-changing target-features today, right? like +fp64 or whatever
<JamesMunns[m]>
adamgreig[m]: this isn't abi changing on cortex m at least
<aliceryhl[m]>
I mean, I don't know if a hypothetical Cbuild-core-alloc could be stabilized, but my understanding is that most of the complexity is std.
<JamesMunns[m]>
hardfloat 32 and hardfloat 64 use the same ABI
<JamesMunns[m]>
dunno about other architectures
<JamesMunns[m]>
(afaik float registers on both systems are still 32-bit, and f64s span two registers, +fp64 just means you have hardware f64 ops)
<adamgreig[m]>
ah yea, I see that jpster detailed this in his comment
<adamgreig[m]>
the double precision registers alias two single precision ones, yea
<JamesMunns[m]>
aliceryhl[m]: yep, it's worth asking the relevant teams if this is a useful line in the sand to stabilize sooner than later
<JamesMunns[m]>
and maybe keep unstable support for doing the same for std targets, until that also gets moved forwards
<bartmassey[m]>
andar1an: The stuff you can use from `std` in `no-std` is the stuff coming from the `core` crate. Take a look at `core` crate https://doc.rust-lang.org/core/ . Folks with lots of RAM also sometimes add the `alloc` crate https://doc.rust-lang.org/alloc/index.html which gives access to std collections.
<aliceryhl[m]>
I will ask the relevant teams about a potential -Cbuild-core-alloc and get back to you.
<adamgreig[m]>
target-modifier sounds like a nice plan
Foxyloxy_ has joined #rust-embedded
<JamesMunns[m]>
In terms of action items, IMO, it would be:
<JamesMunns[m]>
* Collect all the use cases we have, like "making sure core/alloc/std and the user's code have consistent ABI or error, and maybe warn if inconsistent but compatible target flags", and "cargo should be able to rebuild std automatically if it can
<adamgreig[m]>
and then I guess separately some cargo magic to have it auto-rebuild when necessary
<JamesMunns[m]>
* Then share that with relevant teams, and collect potential solutions
<JamesMunns[m]>
And note exceptions, like esp32 where they do have std and might also want this goodness
<aliceryhl[m]>
Yeah, I think we will likely be asked for some logic to ensure that target-modifiers are consistent across all compilation units.
<adamgreig[m]>
and this means rustc will have to specifically know about all these flags and what makes them compatible, rather than just punting them to llvm and hoping for the best
<JamesMunns[m]>
Yep, and maybe an initial list of target-modifiers that we would expect to be stable as part of this (and how to expand that list in the future)
<aliceryhl[m]>
To ensure that the flag is not unsound, and instead catches the UB cases.
<JamesMunns[m]>
adamgreig[m]: yeah, it sounds like we'll need an audited and allow-listed set of features, instead of "straight to LLVM" target features.
<adamgreig[m]>
might be simpler to just say "must match exactly"? assuming you'll just rebuild everything to make that the case
<aliceryhl[m]>
Yes of course. I imagine we will have to add each target-modifier individually.
<JamesMunns[m]>
adamgreig[m]: maybe, the ABI ones are "must", the perf ones are "should"
<thejpster[m]1>
Alice: are the features you need documented in the Rust platform docs, or elsewhere?
<JamesMunns[m]>
(this might matter more for `rustc` than `cargo`, for `rustc` it might be "error/warn", for `cargo` it might be "lol rebuild if any mismatch)
<adamgreig[m]>
oh, I was imagining perf ones staying as target-feature
<adamgreig[m]>
with target-modifier just for abi ones
<adamgreig[m]>
but maybe we can distinguish the two anyway so only the set of abi ones needs to match
<JamesMunns[m]>
for example on linux, as long as the ABI is good, you don't have to fail the build
Foxyloxy has quit [Ping timeout: 245 seconds]
<adamgreig[m]>
thinking abut it it's still nice to move away from target-feature even for just perf ones
<JamesMunns[m]>
adamgreig[m]: IMO I like the idea of porting "stable target features" over to "target modifiers"
<JamesMunns[m]>
but I don't feel too strongly about it.
<aliceryhl[m]>
So what I imagine for the perf ones is that if we are able to add an -Cbuild-core-alloc then of course we also apply normal target-features to core/alloc when building it.
<aliceryhl[m]>
So things that can be a -Csomething flag or a target feature would also work with core/alloc here.
<JamesMunns[m]>
like, "we've documented what this feature is supposed to do and stated it isn't ABI relevant, and is maybe portable outside of LLVM and what LLVM does" could be useful in this mechanism.
<JamesMunns[m]>
(like if we wanted to move +fp64 to target-modifiers instead of llvm's target-features)
<JamesMunns[m]>
or risc-v vector extensions, or armv8m vector extensions, etc.
<JamesMunns[m]>
instead of specifying how we stably plumb through arbitrary target-features, which might be harder to check/match against
<JamesMunns[m]>
but, again, if other people feel strongly about "leave target features alone", I'm less familiar on the whole end-to-end details of how it might matter :)
Foxyloxy has joined #rust-embedded
<adamgreig[m]>
yea, I like it and moving things away from llvm-defined-magic seems nice
<adamgreig[m]>
only reason not to is if you can simplify compatibility checks by saying "well all target-modifiers must match"
<adamgreig[m]>
but eh, there are other ways to accomplish that
<adamgreig[m]>
having any of these things better documented would be an improvement (though jpster's recent docs updates do make the situation much better)
<jannic[m]>
I put one ticket on the agenda that needs a review. But it's nothing we need to discuss today.
<JamesMunns[m]>
jannic[m]: (Adam did review it already!)
<aliceryhl[m]>
No, thanks for the invite folks! It would be great if we could collaborate on solving these issues.
<jannic[m]>
Ah great! 1 minute ago :-)
<jannic[m]>
Thank you!
<JamesMunns[m]>
aliceryhl[m]: If you start outlining what we mean by "target modifiers", let me know, otherwise I think a link to the chat will do for now, and we can figure out writing the idea up/summarizing in the near future?
<JamesMunns[m]>
(if nobody beats me to it, I'll try to summarize what we discussed on that issue tomorrow, and maybe outline what we think "target-modifiers" could be)
<aliceryhl[m]>
So my current plan is:
<aliceryhl[m]>
1. Figure out the deal with -Zbuild-std.
<aliceryhl[m]>
2. Try to write up some sort of doc that can eventually become an RFC that proposes to stabilize -Cbuild-std for no-std only plus add target modifiers.
<JamesMunns[m]>
Have a great week y'all :)
<adamgreig[m]>
enjoy rustconf!
Foxyloxy_ has joined #rust-embedded
<andar1an[m]1>
Olímpico coffee is yummy - if warm they have a "remix" slush like coffee
<andar1an[m]1>
There are 3 in area of conference space I think haha
Foxyloxy has quit [Ping timeout: 260 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 255 seconds]
Foxyloxy has joined #rust-embedded
Foxyloxy_ has quit [Ping timeout: 252 seconds]
Foxyloxy_ has joined #rust-embedded
Foxyloxy__ has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 246 seconds]
Foxyloxy_ has quit [Ping timeout: 246 seconds]
Foxyloxy has joined #rust-embedded
Foxyloxy__ has quit [Ping timeout: 264 seconds]
Foxyloxy_ has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 252 seconds]
Foxyloxy has joined #rust-embedded
Foxyloxy has quit [Client Quit]
Foxyloxy_ has quit [Read error: Connection reset by peer]