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
norineko has joined #rust-embedded
AdamHorden has quit [Quit: Adam Horden | adam.horden.me]
AdamHorden has joined #rust-embedded
IsaBang[m] has joined #rust-embedded
<IsaBang[m]> <Alistair[m]> "RISC-V or ARM? Or both!" <- Or x86
<IsaBang[m]> * Or x86 (joking)
adamgreig[m] has joined #rust-embedded
<adamgreig[m]> urgh what is wrong with GHA today
<adamgreig[m]> it keeps running a failing clippy check against master instead of against the PR
<adamgreig[m]> so it can't be fixed
<adamgreig[m]> this is dumb
<adamgreig[m]> well, whatever, fixed by changing clippy workflow to not be pull_request_target any more and forcing it to merge
d3zd3z[m] has quit [Quit: Idle timeout reached: 172800s]
YuhanLin[m] has joined #rust-embedded
<YuhanLin[m]> I released a crate that allows DSTs (such as trait objects) to be put on the stack in a homogeneous manner. This can be used to create owned trait objects without any heap allocation. Should be useful for embedded.
takkaryx[m] has joined #rust-embedded
<takkaryx[m]> perhaps an easy question, anyone familiar with using heapless vec's and converting them to a u8 arrays to transmit over wire?
<takkaryx[m]> I'm attempting to use micropb crate, and I have a general protobuf packet getting built into a stream, but when I try to generate the u8 array to hand to a usb driver, it hangs my processor
<takkaryx[m]> * perhaps an easy question, anyone familiar with using heapless vec's and converting them to a u8 arrays to transmit over wire?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/NZXcPvbzZCoUzkZrcLcBAsEl>)
<takkaryx[m]> * perhaps an easy question, anyone familiar with using heapless vec's and converting them to a u8 arrays to transmit over wire?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ivySLvKUuQKQTKDfglAGhvgy>)
<takkaryx[m]> it seems just reading the stream at all causes it to freeze, the Stream is a heapless::Vec
mameluc[m] has joined #rust-embedded
<mameluc[m]> <takkaryx[m]> "perhaps an easy question, anyone..." <- > <@takkaryx:matrix.org> perhaps an easy question, anyone familiar with using heapless vec's and converting them to a u8 arrays to transmit over wire?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/fAPOgKadNFXORSbmuAmcohTW>)
<mameluc[m]> does it hang or panic?
<mameluc[m]> instead of copying the whole stream could you just use as_slice?
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 272 seconds]
dngrs[m] has quit [Quit: Idle timeout reached: 172800s]
korken89[m] has quit [Quit: Idle timeout reached: 172800s]
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
mkj[m] has quit [Quit: Idle timeout reached: 172800s]
PedroFerreira[m] has quit [Quit: Idle timeout reached: 172800s]
limpkin_ has quit [Ping timeout: 255 seconds]
limpkin has joined #rust-embedded
<YuhanLin[m]> Vec::into_array only works if the length of Vec is exactly 64 bytes, but micropb probably encoded less than 64 bytes into the Vec. As suggested, try as_slice instead.
<takkaryx[m]> <mameluc[m]> "does it hang or panic?" <- hangs, I forced a panic and it's a different message.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/RtsLumPDsDEWXHziTGSVJXaN>)
<YuhanLin[m]> What's stream.len()?
<YuhanLin[m]> That loop will definitely panic because stream.len() is less than 64, but doesn't make sense for it to hang in first iteration.
<YuhanLin[m]> Also what's the starting value of i?
<takkaryx[m]> starts at 0, sorry, should have included that.
<takkaryx[m]> > <@mameluc:matrix.org> does it hang or panic?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/TRvHwOXQcKeVwXZmnuPIjDPb>)
<takkaryx[m]> * hangs, I forced a panic and it's a different message.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/whJNZtBjErExIckgxWFBInip>)
<takkaryx[m]> but the output looks like this:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/OskCfNuFWANgqMYzpKWQQUSE>)
<takkaryx[m]> huh, ok, using `as_slice()` somewhat works? it's doing something strange.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/pdfACDoLdClBbkSawpzqzLhT>)
<YuhanLin[m]> OK so it's reading out the first element, which is 0. Since encode_len_delimited encodes the length of the Protobuf message first, that mean the encoded length of telem is 0
<YuhanLin[m]> Also, if you encode to the same stream in a loop, the bytes are going to build up and you'll fill up the Vec eventually unless you clear the stream between iterations.
<YuhanLin[m]> What's the value of telem?
<takkaryx[m]> oh, right, I should do that, and apparently look into the protobuf message is encoded.
<YuhanLin[m]> If those fields are optionals, then you need to set the corresponding fields in _has for all the fields you want to set. This is because _has is used to store presence info for all optional fields. Try this: _has: Accel_::_Hazzer::default().init_time().init_x_accel().init_y_accel().init_z_accel()
<takkaryx[m]> ok, found an issue, was not declaring the _has correctly, it needs to be _has: Accel_::_Hazzer::default().init_time() and it works, added a stream clear and it's getting data!
<takkaryx[m]> ah, yea, that's what I was missing
<YuhanLin[m]> Now that I look at it I should probably make the docs clearer on how to initialize _has correctly.
<takkaryx[m]> oh, you're the author! thank you so much!
<YuhanLin[m]> np
<takkaryx[m]> happy to send some suggesstions if you'd like, though I need to get to work this morning
<takkaryx[m]> s/suggesstions/suggestions/
<YuhanLin[m]> sure
jr-oss has quit [Ping timeout: 255 seconds]
<adamgreig[m]> hi @room, meeting time again! agenda is https://github.com/rust-embedded/wg/discussions/785, please add any discussion topics, and otherwise we'll try and do a bit more issue triage
<JamesMunns[m]> Just re-plugging https://sdr-podcast.com/ - first episode is out now, next episode (with me talking about bbqueue and generics!) will be out in about 12 hours :)
<JamesMunns[m]> I'm also writing the first draft of the Survey in the correct format, I will have a PR open to the /wg repo shortly, we can discuss next week :)
<JamesMunns[m]> https://github.com/rust-embedded/wg/pull/787 now live, open to feedback :)
<adamgreig[m]> cool, that was quick! wanna discuss this first and then do triage afterwards? seems that's all we have on the agenda for today
<JamesMunns[m]> Sure! These are primarily the questions I originally proposed:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/fsQhOHRXrcWRjmcaKoMMTSPN>)
<JamesMunns[m]> We do want to make this as short as possible to make it easy for people to complete, so if people think we can reasonably cut items, then I am open to that! If there are more important questions to be asking, I am open to that as well!
<JamesMunns[m]> If there are any multiple choice options that I missed, feel free to add them (alphabetically) as PR suggestions
<adamgreig[m]> surely we can order the cortex core names to A, R, M :P
<JamesMunns[m]> we still need to coordinate with other folks like Amit (tock-os) crew, as well as sort out "publicity", before we "go live" with the survey
<JamesMunns[m]> adamgreig[m]: I guess I could bend on that one :p
<adamgreig[m]> is it worth mentioning ESP32 alongside xtensa or do we expect everyone using esp32 knows what architecture they're on?
Amit[m] has joined #rust-embedded
<Amit[m]> JamesMunns[m]: I've followed the discussion, what's missing from me (us? People like me?)
<JamesMunns[m]> adamgreig[m]: Open to clarification like `ESP32, ESP32-Sx` for Xtensa and `ESP32-Cx, ESP32-Px` for RISC-V if you think it would be useful!
JamesSizeland[m] has joined #rust-embedded
<JamesSizeland[m]> <JamesMunns[m]> "Just re-plugging https://sdr-..." <- Really enjoyed episode 1! I wonder if you could add some rust keywords to the description to make it show up on podcast searches better?
ejpcmac[m] has joined #rust-embedded
<ejpcmac[m]> <JamesMunns[m]> "https://github.com/rust-embedded..."; <- Seems pretty neat :) I’ll share it at work when it is live !
<JamesMunns[m]> Amit[m]: Just coordination so we can get max publicity, also if the Tock-OS folks have questions or multiple choice answers I've missed!
<adamgreig[m]> probably say "nRF" instead of "nRF52" too I suppose
<JamesMunns[m]> JamesMunns[m]: So: share now for review and feedback, then later to make sure as many people take the survey as possible!
<JamesMunns[m]> adamgreig[m]: oh that's a good call!
<adamgreig[m]> for frameworks maybe a None option?
jannic[m] has joined #rust-embedded
<jannic[m]> I wonder if mentioning cargo as a tool choice is useful. I'd expect something very close to 100% here. And if it's not 100%, it's more likely that people forgot to select it, and not that they really have a workflow without cargo. Or is there a useful workflow for mixed C/rust projects that doesn't involve cargo?
<adamgreig[m]> there are some if you work somewhere like google
<adamgreig[m]> but yea, I don't know that having cargo as an option will tell us much
<adamgreig[m]> cross might be interesting
<adamgreig[m]> though I guess it's mostly used by people doing embedded linux
<adamgreig[m]> and we're explicitly not talking about that
<adamgreig[m]> (though maybe we should at least ask the question / have it as an option?)
<JamesMunns[m]> (added suggestions for nRF and cross so far)
<JamesMunns[m]> jannic[m]: open to removing it if other people concur!
<JamesMunns[m]> adamgreig[m]: you mean ask about embedded linux stuff?
<jannic[m]> It doesn't really hurt either, but I was thinking about what can be removed to make it shorter overall.
<adamgreig[m]> yea, I wonder if having one answer where we can see how many respondants are doing embedded linux would be useful, it's probably quite a lot of people (and they're probably cortex-a and maybe using cross and such)
sourcebox[m] has joined #rust-embedded
<sourcebox[m]> Is xtask something that could be on the list?
<adamgreig[m]> we don't really have a question to ask about it in though
<adamgreig[m]> xtask is more of a state of mind, right
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]> what if a person marks: "I have not used embedded Rust for any projects" but would want to for example mark what chip's he works with or plan on working with.
<vollbrecht[m]> E.g when we look at the question - What architectures are you using embedded Rust with?
<JamesMunns[m]> All questions are optional, so they can skip ones that don't apply, would you prefer "do you use or plan to use with" for the questions to make that clear?
<ejpcmac[m]> Do you want to know as well whether companies are doing Rust internally, but not shipping in production yet?
<JamesMunns[m]> ejpcmac[m]: I just added an option for that!
<jannic[m]> or devices in development that are not shipping yet?
<vollbrecht[m]> JamesMunns[m]: yeah so people would not skip to answer here, though yeah than it gets more complicated if they for example use it with C but not with Rust so far. Maybe just replace work with "user or plan to use in Rust"
<JamesMunns[m]> vollbrecht[m]: if you could make suggestions on the PR I'd appreciate it!
<adamgreig[m]> I don't think I have any other suggestions atm, thanks for writing it up!
<JamesMunns[m]> Yep! Let's plan to discuss the "promo plan" next week and finalize any feedback then too? If we are all good then, we can publish some time next week
Henk[m] has joined #rust-embedded
<Henk[m]> october
<JamesMunns[m]> (I'll probably drop out now, on vacation, but wanted to get this done, have a good triage :) )
<adamgreig[m]> thanks, hope you're having a nice time!
<Henk[m]> Henk[m]: Apologies my element app is getting goofy. Meant ty type in the search bar
<adamgreig[m]> ok, that just leaves us with the issue triage, the spreadsheet is https://docs.google.com/spreadsheets/d/1FXEx-VxI29a1GMs8w1VqvxeFCsf7NCdpIKabFt8QsHw
<adamgreig[m]> who's around and wants to join in? if there's a few of us we can split the list up
<jannic[m]> I'm around but a bit distracted so I don't know how many I can look at.
bartmassey[m] has joined #rust-embedded
<bartmassey[m]> I want to help, but I'm super-buried in deadlines today 😦. I guess I'll take a couple-three anyhow…
<bartmassey[m]> I vote we put this off until next week. There's always more time next week 😀
<adamgreig[m]> it's always tempting!
<jannic[m]> BTW does someone know what's the state of the pull requests by reitermarkus? They are open since January and one of them is approved?
<bartmassey[m]> We should just dedicate the whole meeting to triage, with no other issue discussion.
<bartmassey[m]> Pull requests on?
<Henk[m]> I can join next week
<jannic[m]> wg
<Henk[m]> My room is like 100 degrees C right now
rmsyn[m] has joined #rust-embedded
<rmsyn[m]> are there any RISC-V related items to take care of?
<adamgreig[m]> rmsyn: I think https://github.com/rust-embedded/wg/issues/361 is the only needs-triage open issue about risc-v
<adamgreig[m]> jannic: oh, wow, yea, those have been open a while
<adamgreig[m]> the status is "the teams didn't approve and/or someone had concerns, so they've not been merged", but I think ideally the hal and linux teams would have a chat to discuss them and merge or close them
<adamgreig[m]> and 727 needs updating to just remove from tools team and merge that
lehmrob has joined #rust-embedded
<jannic[m]> reitermarkus: Are you still around or did you give up after you didn't get an update on these PRs for months?
<adamgreig[m]> I've fixed 727 up and merged that
<adamgreig[m]> there was also https://github.com/rust-embedded/wg/pull/729 which was merged at the time
<jannic[m]> Good catch, I didn't notice that. I guess the others can be closed for now?
<adamgreig[m]> yea, I think that makes sense
<adamgreig[m]> I've triaged the triage list a bit too 😅
devianjeff[m] has joined #rust-embedded
<devianjeff[m]> If you're struggling for money, I have a couple of glitch that pay and are legit. Got a couple instant ones too. Either way you look at it,ask for more info and imma put you through the glitch... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/BvlrDrWyTsSMWpIfEeEUIJAK>)
devianjeff[m] has left #rust-embedded [#rust-embedded]
geky[m] has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]> great, thanks everyone! we can resume some triage next time, have a good week :)
andar1an[m] has quit [Quit: Idle timeout reached: 172800s]
jr-oss has joined #rust-embedded
braincode[m] has joined #rust-embedded
<braincode[m]> <9names> "I'm not an insider, but I assume..." <- > <@9names:matrix.org> I'm not an insider, but I assume everyone is busy finalising rust 2024 edition (we're only 2 releases away).
<braincode[m]> > Given the vibes in said issues, i also wouldn't hold my breath for a change of approach to TAIT any time soon
<braincode[m]> I see, makes sense, thanks for the insight... TAIT issues being https://github.com/rust-lang/rust/issues/107645 and https://github.com/embassy-rs/embassy/issues/2454 for the current embassy workarounds (and bug?), not sure if there are any other followups elsewhere.
lehmrob has quit [Quit: Konversation terminated!]
<dirbaio[m]> <braincode[m]> "> <@9names:matrix.org> I'm not..." <- "generics in embassy tasks" has nothing to do with TAIT. That one is fundamentally unfixable until Rust allows generic statics.
<dirbaio[m]> TAIT doesn't allow making generic statics.
<dirbaio[m]> the current implementation is still "defining scope is functions that mention the TAIT in the signature". That, combined with https://github.com/rust-lang/rust/pull/113169 makes the current TAIT quite unusable (which is what I was arguing in #107645...)
<dirbaio[m]> it'll become usable again when #[defines] is implemented
<dirbaio[m]> until then ... 🤷
<dirbaio[m]> (note embassy doesn't use TAIT anymore, it uses impl_trait_in_assoc_type only, and only optionally if you explicitly enable the nightly feature. so embassy itself is not affected anymore, but users trying to use TAIT with it are...)
NishanthMenon has quit [Ping timeout: 252 seconds]
dnm has quit [Ping timeout: 252 seconds]
NishanthMenon has joined #rust-embedded
dnm has joined #rust-embedded
Dherse[m] has quit [Quit: Idle timeout reached: 172800s]