<JamesMunns[m]>
diondokter[m]: true, but you choose where you put the `await`s as much as you choose where the `?`s go.
<diondokter[m]>
Hmmm kinda...
<JamesMunns[m]>
JamesMunns[m]: agreed you don't make the decision the same way, the choice comes externally, but you choose where the points lie.
AtleoS has joined #rust-embedded
NiaLinaLunaStorm has joined #rust-embedded
<NiaLinaLunaStorm>
I need help, figuring out, why the USB HID report sent to my device is only read, when the device also sends a report. Ig. I fail to understand something here...
<NiaLinaLunaStorm>
As I understand it, it should skip the entire sending block, if the report didn't change
<NiaLinaLunaStorm>
but idk why it then still waits for sending a report before going to the reading part
IlPalazzo-ojiisa has joined #rust-embedded
<JamesMunns[m]>
it's possible that the PC could wait to have received a report before it sends the next report? I'm looking through the HID spec now and don't see anything, but I could believe it. AFAIK most devices poll and send a report at a regular interval, could be some sort of pseudo flow control to prevent overwhelming keyboards that can't handle "too many" reports?
<JamesMunns[m]>
(this is a guess)
<JamesMunns[m]>
Nia / Lina / Luna / Storm / Lexi check this out:
<NiaLinaLunaStorm>
oki, so I need to figure out time stuff, thanks
<JamesMunns[m]>
The alternative is to basically send data continuously, which is probably fine, because you will be limited to the USB line rate basically (one control transfer per millisecond, IIRC?)
<eddie1o[m]>
Hi everyone! I'm trying to read out the temperature from a MAX6675 thermocouple connected via SPI Interface on ESP32, but the readings are always 0. Can you see what am I doing wrong, or how can I debug the SPI interface? Thanks!
<JamesMunns[m]>
Tho you are also providing VCC of 5v, which I'm not sure if the ESP32 will tolerate, you might need to use 3.3v instead
<eddie1o[m]>
Sorry, the upload function is pretty weird
<JamesMunns[m]>
Giving the MAX6675 5V means it will "speak" 5V to your ESP32, which might damage it.
<eddie1o[m]>
JamesMunns[m]: I've also tried 3,3V on different esp32 (in case I've damaged it) but same result
<JamesMunns[m]>
eddie1o[m]: Yeah, either way, you definitely want to use the 3V3 pin for power and not 5V.
<JamesMunns[m]>
wiring: 15 grey SCK, 17 purple MAX CS, 18 blue SDO
<JamesMunns[m]>
code: 15 SCK, 17 SDO, 18 CSN
<JamesMunns[m]>
you have your CSN and SDO wires backwards from the code
eddie1o[m] has left #rust-embedded [#rust-embedded]
<JamesMunns[m]>
wait, did eddie get banned?
barnabyw[m] has joined #rust-embedded
<barnabyw[m]>
was that ban correct? seemed like eddie was asking a legit question?
<barnabyw[m]>
but I didn’t see the deleted messages
<JamesMunns[m]>
if so, it was probably a bot
<barnabyw[m]>
were they trying to upload code?
<JamesMunns[m]>
yeah, I see it in the mod logs, working on fixing...
<JamesMunns[m]>
The bot didn't like "join and immediately post a picture", and interpreted that as a spam behavior.
<JamesMunns[m]>
I sent eddie a DM while I'm waiting to figure out how to tell the bot to undo that :p
osbj_nova[m] has joined #rust-embedded
<osbj_nova[m]>
Hello, new to Rust and Matrix as well... Just wanted to say hi and that the "Awesome Embedded Rust" is indeed Awesome... Think I just opened like 20 tabs that I found interesting :D
<JamesMunns[m]>
Got the ban cleared, invited the user back, thanks for spotting barnabyw, my client doesn't show join/leave/ban events since it's so noisy
<JamesMunns[m]>
(in the future, feel free to ping me or Adam if that happens again, we can reverse the bot ban)
<diondokter[m]>
<osbj_nova[m]> "> <@diondokter:matrix.org..." <- > <@osbj_nova:matrix.org> Watchpoint / Breakpoint on memory access maybe? Not very practical unless it's possible to set it to watch more than the size of a datatype though... Which I'm not sure how.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/XMfoklMEokgHiSAkjJIbtJPU>)
<diondokter[m]>
The problem is that the compiler doesn't really generate symbols for pretty much anything in rodata
<diondokter[m]>
There were only 2 in my case
<JamesMunns[m]>
JamesMunns[m]: you can look at the start and end linker section labels, and get named objects for that. Usually they show up in that case, and if they don't a lot of the time are static initialization values
starblue has joined #rust-embedded
AtleoS has quit [Ping timeout: 268 seconds]
eddie1o[m] has joined #rust-embedded
<eddie1o[m]>
<JamesMunns[m]> "you have your CSN and SDO..." <- Thanks! I've swapped the blue and purple wires, but it didn't change the result. As I see, the bot has deleted some of my pictures, I'll add the code again in a moment
<eddie1o[m]>
and here again the updated wiring, white is connected to +3.3V and black to GND
<JamesMunns[m]>
You also want the OUT of the MAX device to be to the IN of your ESP
<JamesMunns[m]>
so, you want a dummy out pin eddie1o, and a real input pin
<JamesMunns[m]>
So try moving that blue cable to pin 16 instead of 17
<JamesMunns[m]>
(or swap the pins in software)
<eddie1o[m]>
Works like charm! Thanks a lot!
<JamesMunns[m]>
Hell yeah!
<eddie1o[m]>
This time the problem was between the display and the chair 😉
<JamesMunns[m]>
it's all a learning experience :) I feel like 90% of embedded issues are "it's not wired up right/reliably", so it's always the first thing I triple check!
dygear[m] has joined #rust-embedded
<dygear[m]>
I'm sorry for this basic question. I want to use the rust type system, namely an enum that holds the data for each command that I can send the device across the wire. The problem that I'm having is that it's always allocating the size of the largest member of the enum type. Is there a way to only have it use the size of the member involved? Is... (full message at
<JamesMunns[m]>
well, the in-memory part - it will always be the size of the largest member
<JamesMunns[m]>
if you are talking about "how to serialize this", are you just casting to bytes and sending that? (that might be UB), or are you using a serialization library?
<dygear[m]>
I'm not using anything right now. I was hoping to be able to do it with just the type system and I was hoping that there was something built in to Rust that I could use.
<JamesMunns[m]>
I'm guessing this is talking with an existing device? e.g. you want to talk to your sensor over UART or something? Or do you control the code on both sides?
<dygear[m]>
I only control the host side. The external device I do not have control of their firware so I have to talk to them using their expected byte size and formatting.
<dygear[m]>
Oh, I got ya. I'm going to have to allocate another buffer, but it's not a crazy amount of memory right now for the targetted RP2040 / ESP-32C.
<JamesMunns[m]>
yep, that could work! Tho be careful about passing around large types - sometimes you can end up with multiple "slots" on the stack if you pass them up and down. Instead, you might want to write a driver crate, on top of a crate like `embedded-io`, so you have a `MySensor` type, that has methods like `sensor.write_notepad(&mut uart, &contents)` instead
<JamesMunns[m]>
(embedded-hal is home of all the interface abstractions except serial ports, because they are kinda special, so they live in embedded-io(-async) instead)
<JamesMunns[m]>
new probably won't take &mut self, it would usually look like `fn new(uart: UART, address: Option<Address>) -> Self`, but I haven't seen the rest of your code :)
<dygear[m]>
Its here, I don't think it's the most current version that I'm working on as I haven't pushed the partial changes I've made, but it's fairly close.
<JamesMunns[m]>
I'm not sure what the new part does if you already have a UART at creation! But you know better than I would :)
<dygear[m]>
In still in the design phase, so nothing is concret.
<dygear[m]>
Ah, sick! Thank you! I was wondering how other people do this.
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
hi @room, welcome back! it's meeting time again, I'm still writing up some agenda items to recap RustNL but the link is https://hackmd.io/TKPOcuQaRq-ZasXBdy_FhA, please add anything you'd like to announce or discuss and we'll start in a few minutes
<dirbaio[m]>
forgot to clear the attendee list?
<dirbaio[m]>
cleared it for you, hopefully I didn't remove anyone actually attending
Amit[m] has joined #rust-embedded
<Amit[m]>
Mind if I just lurk on the meeting today?
<JamesMunns[m]>
Amit[m]: strict open door policy :)
<adamgreig[m]>
dirbaio[m]: aah thanks 😅
<adamgreig[m]>
whew actually there was a lot to summarise! let's start and I'll fill in the last few bits as we go
avery71[m] has joined #rust-embedded
<avery71[m]>
Amit[m]: Lurking is what some of us do best
<adamgreig[m]>
first off, any announcements?
<JamesMunns[m]>
not official, but I've started working towards postcard 2.0 (reminder: the WIRE FORMAT won't change, still compat with 1.0, just breaking API changes). Open to hearing any feedback, long desired changes, or open to anyone interested in sponsoring the release (1.0 was sponsored by Mozilla, which was much appreciated)!
<JamesMunns[m]>
Feel free to send me a DM with any questions, or drop by the issue tracker of the repo
<JamesMunns[m]>
* not official, but I've started working towards postcard 2.0 (reminder: the WIRE FORMAT won't change, still compat with 1.0, just breaking API changes). Open to hearing any feedback, long desired changes, or open to anyone interested in sponsoring the release (1.0 was sponsored by Mozilla, which was much appreciated)!
<JamesMunns[m]>
Feel free to send me a DM with any questions, or drop by the issue tracker of the repo
<adamgreig[m]>
just briefly as well, svd2rust 0.33.2 and 0.33.3 were released, with mostly minor changes
<adamgreig[m]>
the main topic for this week is what happened at RustNL last week and various actions coming from that, though I'll try and keep a few minutes at the end for the CI topics
<adamgreig[m]>
thanks everyone who was able to come, it was great to meet many of you (again or for the first time) and I think it was a really good conference/unconference!
<adamgreig[m]>
for everyone who couldn't make it I've written up a very brief summary in the minutes, but there's a more complete set of minutes from the conf itself here: https://hackmd.io/p6bQ0OzqTj-R9ra11LvP8A
<JamesMunns[m]>
(also if you want to see the talks, the livestream is still up):
<adamgreig[m]>
I'll avoid just typing that all into matrix 😅 there are a handful of discussions which resulted in a consensus at the conf, and we'll be getting some RFCs soon so everyone has a chance to discuss and then formally accept them
<adamgreig[m]>
I think that's the main conclusions but if anyone else remembers more please mention them!
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
One docs-related thing not on the list: if folks are willing there will be an online "docs sprint" in a few weeks. We'll try to find a time that works for everybody for a sync meeting, but also do a bunch of stuff async. The idea is to have people get together over a couple of days and write a bunch in an organized fashion. More info as I figure out an actual agenda.
<bartmassey[m]>
Or not, of course: this is one of those things that needs enthusiastic participation from five or more participants. Thoughts welcome.
<Henk[m]>
bartmassey[m]: > <@po8:matrix.org> One docs-related thing not on the list: if folks are willing there will be an online "docs sprint" in a few weeks. We'll try to find a time that works for everybody for a sync meeting, but also do a bunch of stuff async. The idea is to have people get together over a couple of... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/YBKGdQQrQuktZllOXHriIQMM>)
<adamgreig[m]>
I think it probably makes sense to go ahead with RFCs for these and then we can discuss them in turn in meetings
<bartmassey[m]>
We'll put a signup link here in a future meeting and also set up some infra. I want to take time to set this up properly — just wanted a heads-up now.
<adamgreig[m]>
sounds great!
<adamgreig[m]>
bartmassey: in terms of permissions to actually do things with the books, step one is to open a PR on the wg repo adding yourself to the Resources team, and for the existing resources team to approve it, at which point you become a member of that team and get access to the repo too
Noah[m]1 has joined #rust-embedded
<Noah[m]1>
As far as announcements go: We have a documentation session thursday 2000 CEST for probe-rs :) Everyone welcome :)
therealprof[m] has joined #rust-embedded
<therealprof[m]>
Still need to bring in candidates for the council. When's the deadline?
<adamgreig[m]>
the major changes should be done with an RFC, but it can be a single RFC for the entire plan, and it needs to be approved by the resources team, but that doesn't need to be a heavy process or anything
<adamgreig[m]>
therealprof[m]: I don't think there's one yet, but the process is in motion, thanks for the reminder
<adamgreig[m]>
if any wg members are interested in being nominated to the rust leadership council as the launching pad team representative, please let me know
<therealprof[m]>
We have two volunteers from last week, but if anyone is interested.
<therealprof[m]>
* if anyone else is interested.
<adamgreig[m]>
I already know about James Munns and Noah, though Noah I remembered you'd need to be a wg member before you can be nominated
<adamgreig[m]>
for the time being, we plan to keep having a weekly meeting here on tuesdays at 8pm berlin time, but it seems likely we'll also start a semi-regular meeting on zulip to discuss topics that are relevant to both embedded and the rust project
<adamgreig[m]>
by "we" there I just mean "I", though, so please feel free to object or suggest alternatives
NickStevens[m] has joined #rust-embedded
<NickStevens[m]>
Are there thoughts on what would go in Zulip versus this chat?
<Noah[m]1>
adamgreig[m]: no worries, happy to take a job on the wg for now only :) was mostly volunteering in case nobody else will :)
<therealprof[m]>
NickStevens[m]: Zulip allows more structured discussions for specific topics and the other teams are all there.
<therealprof[m]>
You can use whichever you like, this channel is not going away.
<therealprof[m]>
(And we still have the weird channel on discord we can't get rid of for some reason which also sees some discussions every now and then)
<adamgreig[m]>
there's two possibilities with zulip: 1) we swap to using it for more technical discussions, even ones that don't involve the rest of the rust project, because it has good organisation for such discussions and could lower the volume of chat here, or 2) we keep those discussions to matrix and use zulip primarily for discussions that are also of relevance to the rust project
<adamgreig[m]>
if there's apatite for having technical discussions on zulip I'm certainly up for that
<Henk[m]>
Zulip does kinda fix the firehose problem to some extend
<Henk[m]>
Henk[m]: By which I mean the vast stream of messages on this chat
<JamesMunns[m]>
Henk[m]: Now you can have a firehose of firehoses!
<NickStevens[m]>
therealprof[m]: Okay, so to clarify, we're not being asked to move to zulip by anyone on the wider rust teams, we're just being asked to be present there for better coordination? Just want to make sure I'm understanding correctly.
<dirbaio[m]>
fractal firehose
<therealprof[m]>
NickStevens[m]: Yes.
<JamesMunns[m]>
NickStevens[m]: Yep, exactly, "that's where the rust project is", so we've been asked to have a presence there for coordination (in both directions) by the project.
<adamgreig[m]>
we complained we don't get to talk to project people much, they complained we aren't on zulip where they talk, which is a fair point
<NickStevens[m]>
Yup, very fair point, makes sense
<therealprof[m]>
I do find a single matrix channel much easier and friendlier to use for general chat but I do see the point of structured conversations in dedicated topics.
<JamesMunns[m]>
The rust embedded mullet: Business in the Zulip, Party in the Matrix
<NickStevens[m]>
Time to add a 6th open chat program during my day 😜
<adamgreig[m]>
at least it's not discord
<therealprof[m]>
NickStevens[m]: I'm running all chat clients in (way too many) browser tabs.
<vollbrecht[m]>
zulip is pretty usable in the browser, if you only want to check occasionally
<adamgreig[m]>
which i'm now on for non-rust reasons anyway 🙃
<therealprof[m]>
We have enough people on Zulip to comply with the request, but of course anyone is very welcome to join the fun as well.
<adamgreig[m]>
as an aside, if you're a wg member and your file here doesn't list a zulip ID but you do have a zulip ID, please let me know and we can get them added: https://github.com/rust-lang/team/tree/master/people
<adamgreig[m]>
are there any other topics from RustNL that either someone who wasn't there would like to hear more about, or that we should discuss now? I think those topics I listed above are the primary outcomes but probably worth individual discussions once the relevant RFCs or whatever are written up
<bartmassey[m]>
Do we have a template RFC or something we should use for these? Or is the rust-lang template RFC what we're working from?
<adamgreig[m]>
for `grounded`/`static mut`, I guess there won't be an RFC yet, so it's worth mentioning that the plan is to keep working on `grounded`'s documentation for a little while before moving it into the wg, so if you're interested or want to help with that, chat to James Munns and check out https://crates.io/crates/grounded
<JamesMunns[m]>
adamgreig[m]: (for context, `grounded` is a crate to capture the stuff we'd use static mut for, but instead provide safe or "more tightly documented unsafe" data structures and methods instead)
<adamgreig[m]>
especially because static mut will be hard broken in edition 2024 😱
<Henk[m]>
adamgreig[m]: This seems something that we may want to add some notes on in the embeddonomicon
<adamgreig[m]>
the other thing that's still quite vague is the concept of a new team that's responsible for coordinating with rust-lang and having meetings on zulip as appropriate, I don't really know what that would look like yet but is anyone interested (in a non-binding sense) in joining such a thing?
<adamgreig[m]>
the embeddonomicon could benefit from an entire chapter about static mut and how to do it, though perhaps that chapter is just the grounded docs-to-be :P
<dirbaio[m]>
me!
<bartmassey[m]>
I'm interested in a non-binding sense 😀
<dirbaio[m]>
I'm kinda already doing that de facto. sometimes they ping me with embedded/async questions :D
<adamgreig[m]>
depending on what direction the project organisation goes, it may be that people in this rust-lang team are the only "rust project" members, with the rest of the wg in some sense outside of the main rust project, but that's currently still further in the future
<bartmassey[m]>
It would be great if someone who knows stuff could review the embeddonomicon and post tagged issues where love is needed. I have been meaning to do this, but I don't know enough stuff and it may be a bit time-consuming.
<dirbaio[m]>
(and sometimes I shout even when unasked 🤣)
<dirbaio[m]>
(the TAIT thing)
<JamesMunns[m]>
bartmassey[m]: I would be open for this, I think I could record a walkthrough of the embedonomicon and make notes
<adamgreig[m]>
"we said WHAT?"
<NickStevens[m]>
After years of having little time to dedicate to the WG except my free time, I now have a position where I'm explicitly being encouraged to participate, so I'd love to get more involved in the "rust project" side of things.
<JamesMunns[m]>
adamgreig[m]: I still need to write the "loljk" follow up to my 2018 rustconf talk: "type states are annoying, actually"
<adamgreig[m]>
"type states considered harmful"
<JamesMunns[m]>
adamgreig[m]: a little a type state (at constructors only), as a treat
<adamgreig[m]>
anything else arising from rustnl that people would like to talk about now?
<NickStevens[m]>
If there's no other RustNL topics, I think the CI stuff is up next? Long story short, while updating CI for some embedded-linux-related I noticed that actions-rs is now deprecated and starting to throw quite a few warnings across numerous RE repos. I've opened https://github.com/rust-embedded/wg/issues/754 to track but before diving into the work I wanted to get float a few things past the group.
<NickStevens[m]>
First is figuring out if we want to standardize on either rust-toolchain or just using rustup. The advantage of rust-toolchain is cleaner GHA integration, the advantage of rustup is less tooling that could be deprecated again in the future.
<JamesMunns[m]>
adamgreig[m]: maybe not right now - but we might want to talk about new/rotating ewg core team members, tho that may be related to the "what if a rust project subteam" discussion
<JamesMunns[m]>
JamesMunns[m]: maybe: get back up to three, then start rotating folks at some point
<NickStevens[m]>
We have quite a few repos in the org, I'm wondering if some sort of standardization might also be in order to make things easier to update going forward. Like having certain checks and architectures standard for all repos. But that involves a lot of different people's code and repos, so I'd like to approach it considerately and not try to force something on everyone.
<JamesMunns[m]>
NickStevens[m]: do we have a standard "CI template" repo at this point? If not, that might be a good first step, then start template-izing the relevant repos
<adamgreig[m]>
I think currently a few repos have moved off actions-rs to either plain rustup or to rust-toolchain?
<adamgreig[m]>
I'm not sure how good the work-to-payoff ratio is for making a standard CI template and using it everywhere
<adamgreig[m]>
there's a lot of repos, CI is a lot of fiddly work, and it's invariably got a lot of differences between projects
<NickStevens[m]>
adamgreig[m]: That's correct, but at my last count there's still around 20 repos using actions-rs.
<adamgreig[m]>
whereas targetted PRs to each repo to just move away from actions-rs can be quite small and easy and simple to review
<sirhcel[m]>
adamgreig[m]: I'm interested in the documentation topics. bartmassey already announced to start a sprint so i'm fine with having my thoughts written down in https://hackmd.io/TKPOcuQaRq-ZasXBdy_FhA and continuing this discussion later.
<adamgreig[m]>
personally I'm not too fussed about rustup vs rust-toolchain, do you think one or the other might make more sense for specific repos?
<Henk[m]>
adamgreig[m]: Alternatively, a list of best practices could be of use here
<sirhcel[m]>
adamgreig[m]: We did this in the last days for serialport-rs because actions-rs produced flaky windows builds since about two weeks.
<adamgreig[m]>
basically both are simple enough that I'm not worried about having a mix, but I'm open to being convinced we should definitely use one or the other
romancardenas[m] has joined #rust-embedded
<romancardenas[m]>
adamgreig[m]: riscv uses rust-toolchain. It is quite flexible and allows you to tweak different CI workflows depending on your crates. But using plain ubuntu with rustup should be exactly the same
<sirhcel[m]>
* two weeks. This is not super embedded but we are building at least for a bunch of targets which a matrix build.
<therealprof[m]>
JamesMunns[m]: There are some instructions in the main repo, but super outdated.
<NickStevens[m]>
Maybe a combination of the two approaches? Do a pass to move off actions-rs and collect learnings while making the move? Then use that to create a template that could be used for future repos.
<bartmassey[m]>
One CI thing we discussed at the event is that a couple different folks (ofc) have/are working on setups for doing CI directly on embedded devices shared over the internets. I think it's super-promising and would solve a lot of problems!
<sirhcel[m]>
* We [did this, * last days](https://github.com/serialport/serialport-rs/pull/188) for, * two weeks. This is not super embedded but we are building at least for a bunch of targets which a matrix build.
<adamgreig[m]>
romancardenas[m]: did you decide on rust-toolchain over plain rustup for any particular reason?
<vollbrecht[m]>
bartmassey[m]: that is super helpfull, but its in general tied to the specifc ecosystem/hardware. Its less relevant for all the drivers out there that work ontop of embedded-hal
<romancardenas[m]>
My experience is that the fmt workflow is copy-pasteable, but usually clippy needs conditional configurations when mixing targets and examples/tests.
<bartmassey[m]>
@vollbrecht In the long run, I'm hoping that this will support drivers on e-h as well. Not sure what I'm missing here?
<romancardenas[m]>
adamgreig[m]: If I remember well, ubuntu@latest did not include rustup when we transitioned. Rust-toolchain eased the workflow a bit
<romancardenas[m]>
* If I remember well, ubuntu:latest did not include rustup when we transitioned. Rust-toolchain eased the workflow a bit
<Henk[m]>
romancardenas[m]: Setting up caching on GH actions is super easy, though, which would drastically improve installation times
<vollbrecht[m]>
vollbrecht[m]: what i am trying to convey here is yes testing on real hardware is better than not testing or only on a host system. But the goal of embedded-hal is to work on many targets, and if we gravitate to only testing certain targets it may shift everything to that targets. But yes some specific testing is better than none !!
<NickStevens[m]>
Even with hardware set up we'd still need something running the build step and doing the compile itself, which GHA seems to be the best bet right now.
<romancardenas[m]>
Henk[m]: Maybe we can provide a template ci.yml file using ubuntu and caching
<JamesMunns[m]>
I gotta run, thank you to both adamgreig and therealprof for running the meeting today, as well as coordinating and planning all of the in-person meetings at RustNL!
<NickStevens[m]>
Seems like there's not any super strong feelings on how we do this though, so long as it works? So I can start going through repos and figuring out what we need and migrating repos on actions-rs to something else. Just be nice if I pop up uninvited with a CI PR in your repo 😃
<adamgreig[m]>
I think for now the main thing is to get everything off actions-rs, and it's not clear there's much in it between rustup or rust-toolchain, so yea
<NickStevens[m]>
* else. Just please be nice
<adamgreig[m]>
thank you for looking into it!
<bartmassey[m]>
👋 See y'all next week!
<adamgreig[m]>
last thing I wanted to very briefly bring to people's attention is this new discussion about CSR access in the riscv crate being safe/unsafe https://github.com/rust-embedded/riscv/issues/209
<adamgreig[m]>
currently in cortex-m it's mostly all unsafe but I'm not sure that's the direction we necessarily want to take in future
<Henk[m]>
Thanks all, see you next time!
<romancardenas[m]>
I would go with ubuntu:latest + rustup + caching. In this way we avoid a "rust-toolchain is deprecated" issue
<adamgreig[m]>
but we're out of time for this week, so maybe we can discuss it further next week
jannic[m] has joined #rust-embedded
<jannic[m]>
I remember that I updated several repos a while ago when action-rs became throwing warnings. If it helps I can provide some examples.
<Henk[m]>
romancardenas[m]: Yes, that would be a big advantage imo
<adamgreig[m]>
thanks for joining everyone, see you next week!
<romancardenas[m]>
See you next week! There is a lot going on in riscv that I would like to discuss with all lf you 😄
<adamgreig[m]>
I'd be a little careful with caching just because it's very easy to end up making the CI even harder to understand and debug, or to cause it to miss dependencies breaking or stuff like that, sometimes in exchange for not much, but it does depend a lot on the specific CI flow
<adamgreig[m]>
I feel bad not highlighting all the riscv stuff I see flying past my inbox each week, please do feel free to even just mention/announce interesting changes if you like romancardenas! but for sure we can discuss them in more detail next week too
<adamgreig[m]>
I appreciate all the work that's going on there ❤️
<dirbaio[m]>
GHA caching sucks. it zips and uploads the entire target dir, then downloads and unzips later, which is slowwww. if cache is too big it can easily make CI slower, not faster.
<NickStevens[m]>
Depending on the build caching may or may not even improve performance. It really depends. So it's best to get things working first and add the caching carefully afterwards in my experience.
<romancardenas[m]>
Don't worry! This academic year has been difficult for me to attend tl these meetings. I'll cach up in summer
<dirbaio[m]>
and you need to cleanup the target dir somehow, otherwise it accumulates crap over time
<NickStevens[m]>
Hahaha yup, dirbaio hit the nail on the head
<dirbaio[m]>
like, if you build with cortex-m 0.7.7 and then 0.7.8 comes out, the 0.7.7 stuff stays in the target dir forever. If you change cargo features of a dep, the built dep with the old cargo features stays there forever too. etc etc
<dirbaio[m]>
and there's no way to ask cargo to clean just the unused stuff
<dirbaio[m]>
it's a disaster :D
<adamgreig[m]>
only for a few years until ubuntu-latest swaps to a new ubuntu release, right? :P
<adamgreig[m]>
jk I'm not actually sure if that clears the cache...
<romancardenas[m]>
I just hope ubuntu 24 installs qemu 8.0+ with apt. The CI workflow for building it from source is way too verbose
<adamgreig[m]>
oh, I might not be able to attend next week, I'm at my next conference 💀 but we'll see
<cr1901>
Ugh, I was asleep ._.
<cr1901>
I'm doing well today apparently lol
<avery71[m]>
<romancardenas[m]> "Don't worry! This academic..." <- it really is like that. The weekly meetings are scheduled at the same time that I was tutoring people (funny enough, about embedded systems)
IlPalazzo-ojiisa has quit [Quit: Leaving.]
Guest16 has joined #rust-embedded
<therealprof[m]>
Yeah, cargo is very happy keeping old stuff around.
<therealprof[m]>
<adamgreig[m]> "oh, I might not be able to..." <- I'll be on vacation the next two weeks, too. During the meeting I'll actually be in Universal Studios Japan. ;)
<sirhcel[m]>
<JamesMunns[m]> "I would be open for this, I..." <- Skimmed through it and it looks like the document could use some care. For example, sketching out [the ideas which finally led to `defmt` is great](https://docs.rust-embedded.org/embedonomicon/logging.html), but the page references `stlog` and we should directly point there. I would like to help here as well. As the PRs and issues look somewhat "dry-aged" (as mine do for
<sirhcel[m]>
serialport-rs 😅), where to coordinate at best? By opening an issue or at the next documentation sprint?
<therealprof[m]>
Dry aged books? Sounds very yummy!