cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
ian_rees[m] has joined #rust-embedded
<ian_rees[m]>
I'm preparing a Rust project for production, setting up dependency vendoring for the first time - is the typical approach to put vendored dependencies in the same repo as the crate/workspace? Just wondering if it might be better to put the dependencies in their own repo, perhaps used as a submodule
<korken89[m]>
<dirbaio[m]> "korken89: https://github.com/..."; <- Awesome, thank you! I gave it a look, nice that you could reuse the `wycheproof` from `salty` :D
<korken89[m]>
I might come with a PR on some opinionated interface changes, lets see if you agree with me :)
raulvt[m] has joined #rust-embedded
<raulvt[m]>
on embedded_hal/linux there is something that prevent two sensors to read on the same bus at same time?
<raulvt[m]>
I have 3 sensors attached to i2c-1, and 2 on i2c-4, actually I'm reading one by one sequentially. I was wondering if I can speedup the lectures using multiple threads
<Lumpio->
Is that a question or did you try and it seemed like there was something preventing parallel access?
<raulvt[m]>
it's a question
<Lumpio->
Oh _the same bus_
<Lumpio->
I2C physically can't access two devices on the same bus at the same time, so using threads is probably not going to help much since you're I/O bound
<Lumpio->
You could parallelize the two different buses though I suppose
<raulvt[m]>
sure, need to test it
<Lumpio->
Or were you trying to find out if it'll _protect_ you from trying to do parallel reads on the same bus if you put them on two different threads for some reason
<raulvt[m]>
my doubt is if I put the common bus sensors in different threads
<Lumpio->
That's a good question, that would depend on how the Linux I2C interface itself works I guess
<Lumpio->
I took a look and there doesn't seem to be a mutex or anything on the Rust side
<Lumpio->
The kernel interface it uses seems to look like it would synchronize correctly but I'm not an expert
<raulvt[m]>
but i don't implement a clone method for my object :S, need to work into this first
<Lumpio->
Yeah there's no way that's going to work. Cannot be proven to be threadsafe.
<Lumpio->
Also spawning new threads every time is not very efficient if that's what you're going for
crabbedhaloablut has joined #rust-embedded
<raulvt[m]>
we can, if know the reading value
<raulvt[m]>
but sure, i will spawn different buses only
<Lumpio->
What does "if know the reading value" mean
<Lumpio->
I was talking about how Rust ensures thread safety, not even anything sensor related
<Lumpio->
You can't borrow "self" like that. Scoped threads might get you a &, but definitely not &mut which you probably need use for updating any values.
<raulvt[m]>
oh, I've a ak09 magnetometer, it have a constant on certain registers ( manufactur code, other stuff). So, if I read it 100 times with other threads in parallel, and it's always the same and no panics...probably linux handle this for us.
<MathiasKoch[m]>
Follow-up question, in case the answer turns out to be "it's not possible to derive in nostd".
<MathiasKoch[m]>
Does anyone have a hand-rolled deserialize implementation that mimics the adjacently tagged enum derive, in a less dynamic way such that it does not require alloc?
dav1d3 has joined #rust-embedded
dav1d has quit [Ping timeout: 258 seconds]
dav1d3 is now known as dav1d
<JamesMunns[m]>
What wire format are you using? I think a lot of those serde attrs only work with formats that do deserialize_any stuff, I know postcard has trouble with a lot of them.
<MathiasKoch[m]>
json, and am forced to that by serverside
<MathiasKoch[m]>
I can live with that, but how would i do that Deserialize impl in practive?
<MathiasKoch[m]>
s/practive/practice/
<JamesMunns[m]>
https://serde.rs/impl-deserialize.html talks about it, I think you'd need to do "visit_map". then "next_key", ensure its "t", "next value" as a &str, then ensure next_key is "c", then deser "next_value" based on the str contents of the first value
<MathiasKoch[m]>
Awesome! Thanks for the pointers, I will take a look 👍️
<JamesMunns[m]>
I'm less familiar with the Map side of serde since postcard doesn't use it as such, but `Visitor` and `MapAccess` are your two main interfaces.
<JamesMunns[m]>
I would bet you could write a proc macro that derives this for enums? but not sure.
<MathiasKoch[m]>
Thanks. I just need the one impl, so for this time i think i'll just see if i can hand-roll a working impl
Guest7221 has left #rust-embedded [Error from remote client]
starblue has joined #rust-embedded
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #rust-embedded
Jonas[m]1 has quit [Quit: Idle timeout reached: 172800s]
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
thejpster[m] has joined #rust-embedded
<thejpster[m]>
I had a call from someone a Big Chip Company, who had questions about the cortex-m-rt entry! proc-macro and why it exists. There's some docs on the macro itself, and there's some more abstract information in the embedonomicon about "a main interface" but maybe there's a missing link between the two.
<thejpster[m]>
Unless anyone knows of some doc that does this that I don't know or have forgotten about?
<thejpster[m]>
* from someone at a Big
<Lumpio->
Let me guess it's mostly there for the weird "static" transform it does
<adamgreig[m]>
Yea. You could just make a no_mangle extern C fn main and it should be fine, the macro makes sure it has the right name and also does the static transform to make it easier to get some &'static
<Lumpio->
I checked out of interest and it also seems to validate that the function returns "!"
<adamgreig[m]>
Maybe they could be asking these questions on its issue tracker rather than phoning people, lol
<Lumpio->
That's technically a nice thing to have as a compile time check.
<adamgreig[m]>
Sure, I guess that makes sense to be sure it doesn't return, though the rt handler will hardfault if it does rather than ub
<Lumpio->
Yes but that's a runtime check
<dirbaio[m]>
perhaps the q is "could it NOT exist"?
<dirbaio[m]>
like, could we use the plain old fn main() like in a regular Rust binary?
<dirbaio[m]>
(with no no_mangle etc)
<dirbaio[m]>
adamgreig[m]: but then how is thejpster supposed to make money? 🙃
<adamgreig[m]>
dirbaio[m]: Yea, that works fine, right? But we don't document it because you'd lose the compiler checks
<adamgreig[m]>
You don't have to use cmrt at all, after all
<dirbaio[m]>
huh
<dirbaio[m]>
no, it doesn't work: error: requires start lang_item
<dirbaio[m]>
* no, it doesn't work: error: requires 'start' lang_item
EEPROMToast[m] has quit [Quit: Idle timeout reached: 172800s]
nyanko[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]>
seems a bit outdated, #![no_start] is deprecated
kenny has quit [Ping timeout: 260 seconds]
kenny has joined #rust-embedded
<adamgreig[m]>
I mean if you don't use cmrt you still have to sort out the reset vector and bss and jump to your own start, you can't just not have it at all, but even with cmrt, you could replace the entry macro the same way you replace the interrupt macro, it doesn't do anything you can't write yourself
<dirbaio[m]>
sure sure
<dirbaio[m]>
but in std binaries, rust is treating fn main() specially
<dirbaio[m]>
how does that work, and could a cortex-m binary reuse that too?