starblue2 has joined #rust-embedded
starblue1 has quit [Ping timeout: 252 seconds]
rjframe has quit [Quit: Leaving]
emerent has quit [Ping timeout: 272 seconds]
emerent has joined #rust-embedded
GenTooMan has quit [Ping timeout: 244 seconds]
GenTooMan has joined #rust-embedded
neceve has joined #rust-embedded
<re_irc> <@c​hmanie:m​> This might be a weird question but I feel like I've been living on false assumptions. If I have pretty much nothing in the main loop (except for borrowing a mutex and increasing the value), shouldn't it run close to the sysclk? I have one more interrupt at roughly every 10.000 sysclk tick, but the ratio I get...
<re_irc> ... between the main loop and the 10.000th tick is only roughly 5
<re_irc> <@t​halesfragoso:m​> do you have wfi/wfe in the main loop ?
<re_irc> <@c​hmanie:m​> Not explicitly. I'm calling the cortex `free` function but I don't think it should use those
<re_irc> <@t​halesfragoso:m​> So your main loop will run always when there isn't an interrupt being served
<re_irc> <@t​halesfragoso:m​> i.e. a lot
<re_irc> <@c​hmanie:m​> Yes, I assumed so
<re_irc> <@t​halesfragoso:m​> oh, you were saying that it was running way less ? I thought it was way more...
<re_irc> <@c​hmanie:m​> No, way more
<re_irc> <@9​names:m​> note: branch is not a single cycle instruction
<re_irc> <@c​hmanie:m​> So I assumed the loop would be running in the 1000s times more than the interrupt
<re_irc> <@c​hmanie:m​> But not as low as 5
<re_irc> <@t​halesfragoso:m​> yeah, you will have a good chunk of instructions to get the mutex and increment stuff
<re_irc> <@t​halesfragoso:m​> if it's just a integer try using atomics
<re_irc> <@t​halesfragoso:m​> what is the frequencies involved ? for the sysclk and systick
<re_irc> <@c​hmanie:m​> I'm not looking to improve performance here, I was just startled by the difference between what I measured and was expecting
<re_irc> <@c​hmanie:m​> sysclk is 84mhz, systick is 8khz
<re_irc> <@t​halesfragoso:m​> what opt-level ?
<re_irc> <@9​names:m​> how are you measuring?
<re_irc> <@c​hmanie:m​> Hm well yeah maybe this is a schrödinger's cat type situation
<re_irc> <@c​hmanie:m​> I was just debugging it
<re_irc> <@t​halesfragoso:m​> and also, cortex_m::interrupt::free won't be inlined by a stable rust compiler (unless if using plugin-lto), so you get to function calls just to enable and disable interrupts
<re_irc> <@t​halesfragoso:m​> if it's on opt-level=0 this is will be way slower than expected
<re_irc> <@c​hmanie:m​> To be honest I'm not specifying the opt-level, really
<re_irc> <@t​halesfragoso:m​> building with `--release` ?
<re_irc> <@t​halesfragoso:m​> if you're curious, use an `AtomicU32` instead of `cortex_m::interrupt::free` plus build with opt-level="s" and --release
<re_irc> <@c​hmanie:m​> codegen-units = 1
<re_irc> <@c​hmanie:m​> lto = true
<re_irc> <@c​hmanie:m​> This is what I have in `[profile.release]`
<re_irc> <@c​hmanie:m​> debug = true
<re_irc> <@t​halesfragoso:m​> hmm release should default to opt-level = 2
<re_irc> <@t​halesfragoso:m​> which should be somewhat similar to "s" in performance plays, but it won't be able to inline the asm
<re_irc> <@c​hmanie:m​> So with opt-level="s" I'm also getting a ratio of roughly 5-10
<re_irc> <@c​hmanie:m​> Is it the debugging instrumentation that makes it much slower?
<re_irc> <@c​hmanie:m​> I will measure on the hardware level
<re_irc> <@c​hmanie:m​> Thanks so far! I really appreciate it!
<re_irc> <@t​halesfragoso:m​> if you talking about `debug = true`, no, debug information won't be flashed to the micro
<re_irc> <@c​hmanie:m​> Yeah it seems to make sense. It seems with all the instructions put back in I am using my main loop runs with 100khz, which could be improved, I guess
<re_irc> <@b​arafael:m​> Anybody tried stm32wb55 with Bluetooth
<re_irc> <@t​iwalun:m​> Yes, using
<re_irc> <@f​irefrommoonlight:m​> Oh sweet!
<re_irc> <@f​irefrommoonlight:m​> Tangent: I was comparing the BlueNRG and the WB55 module variant: Is the distinction that the BlueNRG is meant to be paired with another MCU, and the WB55 module is all-in-one?
<re_irc> <@f​irefrommoonlight:m​> Note that the NRG is much cheaper
<re_irc> <@f​irefrommoonlight:m​> I'm adding a link to that lib in the stm32hal readme
<re_irc> <@c​hmanie:m​> This seems to be a dumb question to ask but I can't wrap my head around this. I am running this code in my main loop to test the effective frequency:
<re_irc> <@c​hmanie:m​> ```rust
<re_irc> <@c​hmanie:m​> if now == 0 {
<re_irc> <@c​hmanie:m​> fn temp(now: u32) -> Option<[u32; 10000]> {
<re_irc> <@c​hmanie:m​> (this is just for illustration purposes)
starblue2 has quit [Ping timeout: 272 seconds]
starblue2 has joined #rust-embedded
<re_irc> <@a​damgreig:m​> chmanie I don't quite follow what's going on, you mean the call to temp is slow even when now is 0?
<re_irc> <@c​hmanie:m​> Urgh, this is the wrong way round, sorry
<re_irc> <@n​ewam:m​> is there any workaround for this? Trying to get a `usize` for a pointer in const context.
<re_irc> <@n​ewam:m​> error[E0658]: casting pointers to integers in constants is unstable
<re_irc> <@n​ewam:m​> --> gpio/src/
<re_irc> <@n​ewam:m​> |
<re_irc> <@n​ewam:m​> A workaround without using nightly that is ;)
<re_irc> <@c​hmanie:m​> adamgreig: I meant `!=0` instead `==0`. The dip in frequency is not substantial, but it is there
<re_irc> <@c​hmanie:m​> Compared to just returning `None`. I assume in this case it's about optimizations that can't be made
<re_irc> <@a​damgreig:m​> When not 0 it has to set 10000 words to 100 which will take some time
<re_irc> <@a​damgreig:m​> It's not the allocating as such (it's just on the stack) but it has to set it
<re_irc> <@c​hmanie:m​> But shouldn't I just notice it every u32::MAX cycles?
<re_irc> <@c​hmanie:m​> For me in my particular case right now it is a matter of 1.2Mhz (without the last two lines) to 1.07Mhz (with the last two lines)
<re_irc> <@c​hmanie:m​> It's not a big deal but it adds up, it seems
<re_irc> <@a​damgreig:m​> I dunno, are you just calling it with incrementing values of now?
<re_irc> <@d​irbaio:m​> don't cast to usize: `const GPIOA_BASE: *const () = pac::GPIOA::ptr() as *const ();`
<re_irc> <@d​irbaio:m​> usize <=> ptr casts aren't allowed in const
<re_irc> <@c​hmanie:m​> adamgreig: Yeah I increment it using an interrupt. It's too complicated right now, still, sorry. I will simplify
<re_irc> <@a​damgreig:m​> chmanie either way, that's a ton of data to return on the stack, so you might well be better off statically allocating it one way or another and passing a &mut to your function instead
<re_irc> <@c​hmanie:m​> Thanks adamgreig I'll see if I can refactor
<re_irc> <@n​jha:o​> Is this still where #rust-embedded lives? Even the matrix motd says freenode 😟
<re_irc> <@t​herealprof:m​> You came to the right place. Can you point out where you found the freenode notice?
<re_irc> <@n​jha:o​> Welcome to the Rust Embedded chat room! | Bridged to Freenode IRC: #rust-embedded <snip>
<re_irc> <@n​jha:o​> it's entirely possible this is a caching issue though
<re_irc> <@t​herealprof:m​> Super weird. The current MOTD is: Welcome to the Rust Embedded chat room! | Discuss, coordinate, help: | Code of conduct: | Temporary bridge running to #rust-embedded on IRC...
<re_irc> <@n​jha:o​> yeah probably a caching bug in synapse/element then 😐️
<re_irc> <@n​jha:o​> thanks!
<re_irc> <@t​herealprof:m​> No worries, and welcome.
j0m has joined #rust-embedded
j0m has quit [Quit: Ping timeout (120 seconds)]
j0m has joined #rust-embedded
j0m has quit [Quit: Ping timeout (120 seconds)]
j0m has joined #rust-embedded
j0m has quit [Quit: Ping timeout (120 seconds)]
<re_irc> <@p​aul_gd:m​> Hey there, I'm trying to read a toml as a config for my keyboard firmware and I'm unsure on how I'd read the array for the pins
<re_irc> <@p​aul_gd:m​> This is how it currently looks
<re_irc> <@s​ympatron:m​> Can somebody here help me with a lifetime problem?
<re_irc> <@s​ympatron:m​> I am currently working on a no_std implementation of a MsgPack serde (de)serializer, but I can't get the lifetimes to work out.
<re_irc> <@s​ympatron:m​> This is what I am trying to do:
<re_irc> <@s​ympatron:m​> fn test_roundtrip<'a, T: ::serde::Serialize + ::serde::Deserialize<'a> + std::fmt::Debug + PartialEq>(value: T) {
<re_irc> <@d​irbaio:m​> what's with the ✂️ 📝? lol
<re_irc> <@d​irbaio:m​> sympatron: the issue is the `'a` lifetime is decided by the caller of `test_roundtrip`
<re_irc> <@d​irbaio:m​> so when you do `T: ::serde::Deserialize<'a>` it doesn't mean "T implements Deserialize", it means "T implements deserialize for a very particular lifetime `'a` that's chosen by the caller"
<re_irc> <@d​irbaio:m​> for example if `'a` was `'static` then the buffer would have to be borrowed for `'static`, which it can't because it's a local var
<re_irc> <@d​irbaio:m​> if you want to say "T implements Deserialize for any lifetime" you have to do `T: for<'a> ::serde::Deserialize<'a>`
<re_irc> <@d​irbaio:m​> and then it works :)
<re_irc> <@s​ympatron:m​> Thank you so much! This literally cost me hours! I have seen this `for<>` syntax but never understood what it's supposed to mean. Guess I have still some reading to do...
<re_irc> <@d​irbaio:m​> yeah it's very subtle :S
<re_irc> <@s​ympatron:m​> Ok, now I get `implementation of Deserialize is not general enough` when I try to call it like that: `test_roundtrip("")`
<re_irc> <@d​irbaio:m​> uuh
<re_irc> <@d​irbaio:m​> fun
<re_irc> <@d​irbaio:m​> I think the issue is
<re_irc> <@d​irbaio:m​> you're passing a `&'a str` which gets serialized into `buf`
<re_irc> <@d​irbaio:m​> but then trying to deserialize out of `buf` into a `&'a str`, but that won't work because buf lives for less than `'a`
<re_irc> <@d​irbaio:m​> like, it can deserialize into &str, but not `&'a str`
<re_irc> <@d​irbaio:m​> no idea how to fix it though
VShell has joined #rust-embedded
<re_irc> <@d​irbaio:m​> meh.. you can workaround it by passing the buf from outside the func
<re_irc> <@d​irbaio:m​> because you can then require the buffer is 'a too
<re_irc> <@d​irbaio:m​> I don't know if it's fixable in a "proper" way
VShell has joined #rust-embedded
VShell has quit [Changing host]
Shell has quit [Killed (NickServ (GHOST command used by VShell))]
VShell is now known as Shell
<re_irc> <@s​ympatron:m​> This might be good enough for now. I will have to think a bout this/start to use it and see. Thank you very much!
Ekho has quit [Ping timeout: 264 seconds]
Ekho- has joined #rust-embedded
<re_irc> <@d​irbaio:m​> test
rektide has quit [Ping timeout: 265 seconds]
rektide has joined #rust-embedded
neceve has quit [Ping timeout: 264 seconds]
Amanieu_ has joined #rust-embedded
Amanieu has quit [Ping timeout: 265 seconds]
agg has quit [Ping timeout: 265 seconds]
nohit has quit [Ping timeout: 265 seconds]
agg has joined #rust-embedded
nohit has joined #rust-embedded
Ultrasauce is now known as sauce