ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
spinfast[m] has joined #rust-embedded
<spinfast[m]> is anyone working on cranelift for various mcu targets by any chance?
<spinfast[m]> seems pretty awesome
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
<f0rte[m]> Anybody know how/if I can toss an embassy executor task inside a mod? I've got a pretty big project and I organize by having multiple separate files then doing mod $file and use, but I'd like to put tasks in these files and not just functions.
<f0rte[m]> right now I am kinda "working around" but putting my tasks inside pub async functions then having "thin" tasks in main that just call that fn, but just curious if there is a better way
<f0rte[m]> Ah figured it out. Spawner::for_current_executor() to the rescue.
IlPalazzo-ojiisa has quit [Quit: Leaving.]
dsmith has quit [Ping timeout: 246 seconds]
dsmith has joined #rust-embedded
<JamesMunns[m]> <f0rte[m]> "right now I am kinda "working..." <- tbh this is what I usually do, or pass the spawner around, but what you said works too! I think it's mostly preference which one you choose.
<JamesMunns[m]> keeping async fns in a mod (or a whole separate lib) can make testing a little easier too, tho that requires you to use generics e-h-async types at that boundary too, which I don't always do.
<diondokter[m]> JamesMunns[m]: Depends. That lib could also just know about the HAL. But that makes testing worse again
<JamesMunns[m]> yeah, sorry I meant "on host"/unit testing - where you can't really use the actual HAL, without a lot of trickery
<JamesMunns[m]> having async fns in a mod/lib is also nice when you DO need generics, like if you want to spawn two tasks, each doing a serial port thing with separate serial ports
<JamesMunns[m]> that being said, that doesn't actually occur very often either :D
<diondokter[m]> Yep, true
<JamesMunns[m]> (e.g. using the EXACT same logic with two ports inside of a single project)
<JamesMunns[m]> tho, more often, it's "the same logic on two different chips", where generics and a separate lib helps again
<JamesMunns[m]> basically, oh so many options :p
Darius has quit [Ping timeout: 256 seconds]
Darius has joined #rust-embedded
Foxyloxy_ has joined #rust-embedded
Foxyloxy has quit [Read error: Connection reset by peer]
TomB[m] has joined #rust-embedded
<TomB[m]> anyone else ever see missing messages on matrix? like on one device I see messages, another I don't, from the same channel
<ryan-summers[m]> Yeah I do all the time for the time periods that I have my laptop turned off
<diondokter[m]> Hmmm never noticed that...
<diondokter[m]> We all three have matrix.org accounts...
<JamesMunns[m]> Yeah, I've seen it, tho often it is "fixed" if I close the app and reopen it
<diondokter[m]> I'm using Element as my client everywhere
<JamesMunns[m]> (using Beeper's clients across MacOS and Android)
<TomB[m]> how do you "close" the web app?
<TomB[m]> reloading the page doesn't do it
<JamesMunns[m]> ah, that idk, I have desktop apps and android apps
<JamesMunns[m]> I don't use the web interface. Logout login I'd guess?
<TomB[m]> aren't they all basically web clients anyways, or is there actually a native client that is nice and doesn't use electron like things
<TomB[m]> sometimes I just miss irc and weechat... really
<JamesMunns[m]> beeper is also electron, tho their newest android app isn't based on element's clients, so maybe they'll port that over to desktop too? Idk.
jannic[m] has joined #rust-embedded
<jannic[m]> <TomB[m]> "how do you "close" the web app?" <- The element web app has a "clear cache an reload" option hidden at the bottom of Settings / Help & About. Perhaps that could help?
IlPalazzo-ojiisa has joined #rust-embedded
<TomB[m]> jannic[m]: doesn't seem to have
<TomB[m]> confusing as heck
<TomB[m]> I also tried leaving/rejoining the room without success
<TomB[m]> could I somehow add the imxrt-rs channel to the rust community? how does that work or who can do that?
<TomB[m]> adamgreig: could you please add imxrt-rs, looks like you are the admin
SimonJohansson[m has joined #rust-embedded
<SimonJohansson[m> Hello! Is anyone aware if there are any performance difference between RTIC v1 and v2, or is that hard to quantify?
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #rust-embedded
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
rustyboy[m] has quit [Quit: Idle timeout reached: 172800s]
bartmassey[m] has joined #rust-embedded
<bartmassey[m]> Are we meeting today?
newam[m] has joined #rust-embedded
<newam[m]> Might be an hour later, daylight savings things.
<bartmassey[m]> Cool. Will check back then. Thanks.
<dirbaio[m]> yeah it's at 8pm western europe time, so in 1h
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
adamgreig[m] has joined #rust-embedded
<adamgreig[m]> hi @room, meeting time again! agenda is https://hackmd.io/-8LiTEfURtSlgoCwsBIFvg, please add anything you'd like to announce/discuss and we'll kick off in a few mins
mabez[m] has quit [Quit: Idle timeout reached: 172800s]
K900 has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]> I don't have any announcements for once, so if anyone has anything to announce please go ahead :)
<adamgreig[m]> I guess we can wave posborne off for 6 months, have a good trip!
posborne[m] has joined #rust-embedded
<posborne[m]> Thanks! It will be an adventure for sure.
<adamgreig[m]> sounds like it!
<adamgreig[m]> only point I noticed come in this week then is about having multiple operations on i2c that you wanted to have repeated starts, where currently they are merged, but I don't spot any hal team people here atm
<TomB[m]> I believe nrf twim/twi enforces this sort of usage pattern?
therealprof[m] has joined #rust-embedded
<therealprof[m]> I'm here but don't have anything to note.
<bartmassey[m]> I just finished teaching my 10-week Rust Embedded course. I need to do a writeup of some kind covering stuff relevant here. tldr; went well.
<TomB[m]> * https://github.com/zephyrproject-rtos/zephyr/issues/11612 is maybe related... I know there's some quirks with nrf twi
<bartmassey[m]> Teaching will be easier next time, when it does not cross the HAL 1.0 transition 😀
<adamgreig[m]> nice!
<bartmassey[m]> Oh, and I've been working on some PRs for the various Microbit stuff in preparation for working on Discovery Book and Embassy Discovery Book upgrades.
<bartmassey[m]> Henk and I are planning to spend a week doing stuff in a couple of weeks.
<bartmassey[m]> Unfortunately, because US Daylight Savings Time issues, if I'm going to get lunch today it's now. I'll check back later for further discussion.
<adamgreig[m]> looks like a quiet meeting this week, does anyone have anything else they want to discuss?
<therealprof[m]> I got nothing. 😅
<JamesMunns[m]> Keep suggesting things for RustNL discussion!
<JamesMunns[m]> Unique opportunity for collaboration and all that!
<dirbaio[m]> o/
<adamgreig[m]> <TomB[m]> "adamgreig: could you please..." <- I can't find the imxrt-rs room, could you send the link?
<adamgreig[m]> \o
<TomB[m]> adamgreig[m]: https://matrix.to/#/#imxrt-rs:matrix.org
<adamgreig[m]> thanks, added!
jamwaffles[m] has joined #rust-embedded
<jamwaffles[m]> Hey all, I'd like to transfer ownership of 3 display drivers I started to someone who can give them the care they need. If you'd like to take ownership of something, please leave a comment on these issues:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/PLZqzkLlINTskGCjeGPWoeLH>)
<jamwaffles[m]> Not sure where else I could post this, so let me know if there's a place to get more reach
<dirbaio[m]> rust-embedded-community?
<dirbaio[m]> * rust-embedded-community mayb?
<dirbaio[m]> * rust-embedded-community maybe?
eldruin[m] has joined #rust-embedded
<eldruin[m]> sounds like a good fit for the r-e-c indeed.
<jamwaffles[m]> Sweet. I'll give it a day or two if someone wants to take over, otherwise I'll move them over there
<eldruin[m]> sure
<eldruin[m]> feel free to contact me if you actually want to transfer them
<jamwaffles[m]> Do I need to do anything more than moving them in the GH UI?
<eldruin[m]> You are not able to transfer a repo to an org you do not belong to
<therealprof[m]> Apart from the GH repo you also need to transfer publishing rights on crates.io.
<eldruin[m]> so if you want to transfer them I would just ask you if you want to join the org or not, either is fine
<eldruin[m]> * want to additionally join the
<eldruin[m]> if you join the org you can do everything yourself. if not, you would transfer it to me and I would transfer it to the org
<eldruin[m]> you keep full admin rights either way
<jamwaffles[m]> Ah I see! Joining the org sounds like the best way to do it
<eldruin[m]> the org is there just to ensure that nice embedded projects do not just die
<jamwaffles[m]> therealprof[m]: I can add the org as one of the authors in cargo.toml can't I?
<eldruin[m]> publishing rights are separate from copyright metadata in the cargo.toml
<eldruin[m]> to grant publishing rights you do something like cargo owner ...
<eldruin[m]> that, exactly
<jamwaffles[m]> Ah, yes of course. I'll remember to do that too
<eldruin[m]> to join the org, please open a PR in the meta repo and add yourself to the list in the readme
<eldruin[m]> * to join the org, please open a PR in the [`meta` repo](https://github.com/rust-embedded-community/meta) and add yourself to the list in the readme
RoyBuitenhuis[m] has quit [Quit: Idle timeout reached: 172800s]
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
thejpster[m] has joined #rust-embedded
<thejpster[m]> Sorry, was at the Rust Nation speaker reception, after two days of Rust Leaders summit. We talked a lot about working groups.
<adamgreig[m]> Anything in particular to report (or want to save it for next meeting)? (I'm afk, bbl)
<wyager[m]> What's the current state of compiling Rust position-independent code for ARM? I am wondering about the feasibility of creating "applets" that can e.g. be loaded into RAM from external flash.
<dirbaio[m]> states is
<dirbaio[m]> - "embedded PIC" (ROPI/RWPI) doesn't work at all
<dirbaio[m]> - "regular PIC" works fine (I think?) but then you need to write your own loader that applies relocations, just like a desktop OS would do
<adamgreig[m]> If you can always run from the same part of ram you could even skip PIC and just build for that one location
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
khionu[m] has quit [Quit: Idle timeout reached: 172800s]
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #rust-embedded
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
M9names[m] has joined #rust-embedded
<M9names[m]> if you have a fixed number of applet locations, you can do the above but link the applet for each location.
<M9names[m]> i would think there's a very good chance the firmware binary would be the same with just a few address changes - maybe you could store these as patches against the base image?
<M9names[m]> not sure if this is less effort than building your own loader to handle relocations, but it certainly sounds simpler in my head.
<dirbaio[m]> these "patches" is exactly what relocations are 🙃