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]>
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
<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.
<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
<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]>
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?
<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]>
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?
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
<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]