<GrantM11235[m]>
<jannic[m]> "Thanks to everybody involved..." <- > <@jannic:matrix.org> Thanks to everybody involved that you didn't stick to the planned 1.0.0 release date, but take the time to discuss the `&mut self` question. While personally I guess that both approaches have their merits and there won't be a clear winner... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/zrVaJRlsxMmQfDmopEjlPlUe>)
<GrantM11235[m]>
Now I just have to turn off my notifications so that I don't get distracted and forget to sleep 😬
Amanieu has quit [Ping timeout: 255 seconds]
Guest7282 has joined #rust-embedded
notgull has quit [Ping timeout: 245 seconds]
notgull has joined #rust-embedded
Guest7282 has left #rust-embedded [Error from remote client]
<korken89[m]>
Another option is to have the state live in the RAM of the softdevice so it does not need to live in the user side. But this has some other issues related to allocating RAM for the softdevicel
<korken89[m]>
* Another option is to have the state live in the RAM of the softdevice so it does not need to live in the user side. But this has some other issues related to allocating RAM for the softdevice.
<korken89[m]>
* Another option is to have the state live in the RAM of the softdevice so it does not need to be created in the user-side. But this has some other issues related to allocating RAM for the softdevice.
<JamesMunns[m]>
Why not just return an opaque repr(c) type? Are you worried about people poking into it?
<JamesMunns[m]>
like, you can have non-pub fields
<korken89[m]>
But is the layout the same on both sides?
<JamesMunns[m]>
if its repr(c), yes
<dirbaio[m]>
this is a crazy hack, but
<dirbaio[m]>
you could do repr(C, align(4)) struct MyOpaqueState([u8; 1024])
<JamesMunns[m]>
repr(c) has a defined layout order/padding/etc.
<dirbaio[m]>
then in the softdevice impl, use the actual type, and add some complie-time assert that it's smaller than 1024 bytes
<dirbaio[m]>
and that align is 4 or less
<dirbaio[m]>
this gives you "room" for growing the type up to 1024 bytes
<korken89[m]>
Can you repr(C) something that contains non repr(C) structs?
<dirbaio[m]>
like even if it's only 1000 bytes today you can grow it a bit
<JamesMunns[m]>
korken89[m]: you can but it wont work
<dirbaio[m]>
* a bit in the future
<korken89[m]>
What I'm currently trying to do is to expose the sha2::Sha256 via the softdevice so the state will contain the Sha256 struct
<JamesMunns[m]>
as in, "it will compile but if you want it to work the way its supposed to all fields need to be repr(c)"
<korken89[m]>
dirbaio[m]: This is my current last-resort :D
<JamesMunns[m]>
you should make your own repr(C) struct you can Into/From, IMO.
<JamesMunns[m]>
or have your own static singleton, or have the user provide an "arena" (basically) like dirbaio suggested
<dirbaio[m]>
yeah you can't make MyOpaqueState actually contain the sha2::Sha256
<dirbaio[m]>
it could break if you upgrade rustc, or if you upgrade the sha2 crate :(
<korken89[m]>
The thing is, only the softdevice will operate on this "memory" so as long as I can construct something that walk and quacks is space and alignment it should work I think
<korken89[m]>
s//`/, s//`/, s/is/in/
<dirbaio[m]>
all you can do is reserve some data with a given align, and then pray updates of rustc or sha2 don't increase it beyond 1024bytes or align=4
<korken89[m]>
But it's in practice "allocating" in userspace as you outlined
<dirbaio[m]>
maybe, just maybe
<dirbaio[m]>
you could do `fn with_sha256(callback: fn(&mut MyOpaqueState))`
<dirbaio[m]>
so you call it, it stack-allocates the state, then calls you back so you can use it
<dirbaio[m]>
but it'd suck to use. you can't use closures, just function pointers, so you can't capture variables. and you can't use async within the closure
<JamesMunns[m]>
Can you hide a sealed type in an public union def? :p
<dirbaio[m]>
s/closure/callback/
notgull has quit [Ping timeout: 256 seconds]
<korken89[m]>
Now we're getting into the proper level of cursed :D
<dirbaio[m]>
that can stlil change size with sha2/rustc updates
<korken89[m]>
Yeah, I think the "allocalted" area must be constructed at runtime given size and alignment from the softdevice API
<korken89[m]>
So nothing can change dues to compilers or crate updates on the userspace application
<korken89[m]>
s/dues/due/
<JamesMunns[m]>
dirbaio[m]: it can, but you could assert the alignment and size
<JamesMunns[m]>
hmm
<korken89[m]>
I mean, after the softdevice is built once one can use Aligned to create the area as it will never change. Just have an assert to check it.
<korken89[m]>
It's not suuper horrible
<korken89[m]>
* I mean, after the softdevice is built once one can use Aligned to create the area as it will never change in size/alignment after that. And just have an assert to check it.
<korken89[m]>
In case of future updates during development
<korken89[m]>
Hmm
<korken89[m]>
Yeah, the more I think about it - without the underlying structs being repr(C) as you say James, I see now way to "compile time" get all the info needed to allocate space for the object without it maybe breaking
crabbedhaloablut has joined #rust-embedded
<korken89[m]>
s//`/, s//`/, s/now/no/
Guest7282 has joined #rust-embedded
<JamesMunns[m]>
The issue is more "there are more than one compile times"
<thejpster[m]>
In C land I’d just have the library mallow what it needs
<thejpster[m]>
mallow?!
<JamesMunns[m]>
that's one way to marsh-all the data
<thejpster[m]>
Yes, mallow and chew, the two memory functions.
<korken89[m]>
Hehe
<korken89[m]>
Yeah if you had an allocator it would be indeed be simpler
notgull has joined #rust-embedded
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
notgull has quit [Ping timeout: 256 seconds]
Guest7282 has left #rust-embedded [Error from remote client]
Guest7282 has joined #rust-embedded
dngrsspookyvisio has quit [Quit: Idle timeout reached: 172800s]
Guest7282 has left #rust-embedded [Error from remote client]
HumanG33k has joined #rust-embedded
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
korken89: I did some testing with your `biquad` crate some days ago. One thing that would be nice to have is the option to use `micromath` instead of `libm`. That would lose some precision but reduces the code size noticably and is acceptable in many cases. What do you think?
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]>
Anyone ever look at the difference between biquad and idsp? Idsp doesn't use libm from what I recall
<korken89[m]>
<sourcebox[m]> "korken89: I did some testing..." <- I think it should be fine :) a PR would be appreciated
<korken89[m]>
<ryan-summers[m]> "Anyone ever look at the differen..." <- libm is used for when you want to calculate the coefficients as it needs cos/sin, else the implementation does not require anything special :)
<sourcebox[m]>
The APIs of libm and micromath are slightly different. I'm not 100% sure how to handle that. One option would be to put sin/cos into a separate function and do the conditional parts inside. Should be inlined anyway.
<sourcebox[m]>
Another thing is the tests as you do some comparison to scipy.
<korken89[m]>
Yeah that sounds good
<korken89[m]>
For micromath one should be a little careful though so the coefficient calculation is sensitive to round-off errors
<korken89[m]>
s/so/as/
<sourcebox[m]>
You use libm as part of num-traits, so that has to be changed also.
<korken89[m]>
Right, I think they could be refactored to not be trait based, but that's a larger rewrite:/
<sourcebox[m]>
I currently use an own implementation of an IIR filter, swapping to micromath did not change something notably.
<sourcebox[m]>
But I only implemented the peaking filter, so I thought about switching to your crate because it contains all the types.
<korken89[m]>
I mean give it a try
<korken89[m]>
Clearly worth it in complexity :)
<korken89[m]>
It's the first create I wrote in Rust so it's not quite up to my standards today :P
<korken89[m]>
s/create/crate/
<sourcebox[m]>
Another interesting thing I noticed is that fact that on a Cortex-M7 the compiler gives a performance boost when processing the two stereo channels at a time. But I have no idea if that could be done in some generic way with your crate.
<sourcebox[m]>
On ESP32 in contrary, it makes everything worse.
<sourcebox[m]>
In that case, the compiler seems to do some optimization with register/memory handling which I estimate gives about 20% better performance. But that has to be checked.
<korken89[m]>
Interesting, is not clear what's different. Looks similar after inlineing
<sourcebox[m]>
This whole function takes 20 cycles for each call.
<sourcebox[m]>
And yes, it uses the same coeffs for both channels as it's often done with stereo EQs.
<korken89[m]>
Right maybe that's it
<sourcebox[m]>
But I also have a version with different settings for the channels, which is also faster than doing it separately.
<korken89[m]>
The reuse would reduce it a bit
<sourcebox[m]>
But as I said, on ESP32 processing the channels separately does a better job.
IlPalazzo-ojiisa has quit [Read error: Connection reset by peer]
IlPalazzo-ojiisa has joined #rust-embedded
ragarnoy[m] has joined #rust-embedded
<ragarnoy[m]>
Hey, any reason why lora-phy was reverted to use embedded-hal rc2 ?
Guest7282 has joined #rust-embedded
<sourcebox[m]>
korken89: After having a closer look at the biquad code, it's not that simple as I thought. Mainly because your crate generically supports floats while micromath only provides functions for f32.
notgull has joined #rust-embedded
Guest30 has joined #rust-embedded
<Guest30>
This will likely be fairly niche, but I'm looking for some help implementing USB Host support on an STM32F407 - the stm32f4xx_hal has some code for device mode, but not host mode. I've got the FSMC working for NAND that I'll have to upstream at some point, and I tried cross-compiling the HAL with no luck - it seems that the HAL isn't performing
<Guest30>
writes to the structure I pass to it. Can anyone point me in the right direction?
rtyler has joined #rust-embedded
Guest30 is now known as dbristow-rs
dbristow-rs[m] has joined #rust-embedded
<dbristow-rs[m]>
I’ve moved to the matrix bridge, please ping me if you have anything suggestions!
dbristow-rs has left #rust-embedded [#rust-embedded]
ChristianHeussy[ has quit [Quit: Idle timeout reached: 172800s]
JoshuaFerguson[m has quit [Quit: Idle timeout reached: 172800s]
<firefrommoonligh>
Interesting: the esp-rs matrix chat is more active than the other embedded rust ones combined, and the group of posters has little overlap. I'm not sure what to make of it yet
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
Wandered over there since I want WiFi on a potential project
sashin[m] has joined #rust-embedded
<sashin[m]>
Hey everyone, I'm trying to go through the rust microbit book and I'm running into some problems
<yae>
Are there general rust channels? I'm using rust in the development of a linear programming library, I don't know if this is relevant to this channel
<rtyler>
yae: there is ##rust, but your mileage may vary
<barnabyw[m]>
looks like probe-rs doesn’t know what chip it’s trying to talk to. perhaps you need to uncomment the relevant chip = line in Embed.toml for that step?
<barnabyw[m]>
looks like the guide assumes you just know to do that for the other steps
<sashin[m]>
yup, that was exactly it
<sashin[m]>
I'm realising that the same structure is in every subfolder
* rtyler
is feeling inspired to dig out his microbit
<barnabyw[m]>
yep, you’ll probably have to repeat some of those same set-up steps a bunch of times. good way of learning I suppose 🙃
<firefrommoonligh>
Hi! Should the rustflags = [ section of .cargo/config.toml go under build, or the target section? The template I've been using, based on Knurling's, places it under target., but the ESP template places it under build`. Thx!
<barnabyw[m]>
probe-rs always needs to know what type of chip it’s connecting to, and if it says it can’t automatically figure it out, that’s a hint that you need to tell it somewhere
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<firefrommoonligh>
THx!
<sourcebox[m]>
firefrommoonlight: If you generate the RUSTFLAGS as env variable from build.rs, you can have it dynamically. That's the most obvious advantage that comes to my mind.
onkoe[m] has joined #rust-embedded
<onkoe[m]>
hey folks! with `embedded-hal` 1.0, is there any ‘new’ place to find the ADC traits?
<onkoe[m]>
or are they completely up to the implementation?