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​atrix.org> 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​atrix.org> do you have wfi/wfe in the main loop ?
<re_irc> <@c​hmanie:m​atrix.org> Not explicitly. I'm calling the cortex `free` function but I don't think it should use those
<re_irc> <@t​halesfragoso:m​atrix.org> So your main loop will run always when there isn't an interrupt being served
<re_irc> <@t​halesfragoso:m​atrix.org> i.e. a lot
<re_irc> <@c​hmanie:m​atrix.org> Yes, I assumed so
<re_irc> <@t​halesfragoso:m​atrix.org> oh, you were saying that it was running way less ? I thought it was way more...
<re_irc> <@c​hmanie:m​atrix.org> No, way more
<re_irc> <@9​names:m​atrix.org> note: branch is not a single cycle instruction
<re_irc> <@c​hmanie:m​atrix.org> So I assumed the loop would be running in the 1000s times more than the interrupt
<re_irc> <@c​hmanie:m​atrix.org> But not as low as 5
<re_irc> <@t​halesfragoso:m​atrix.org> yeah, you will have a good chunk of instructions to get the mutex and increment stuff
<re_irc> <@t​halesfragoso:m​atrix.org> if it's just a integer try using atomics
<re_irc> <@t​halesfragoso:m​atrix.org> what is the frequencies involved ? for the sysclk and systick
<re_irc> <@c​hmanie:m​atrix.org> 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​atrix.org> sysclk is 84mhz, systick is 8khz
<re_irc> <@t​halesfragoso:m​atrix.org> what opt-level ?
<re_irc> <@9​names:m​atrix.org> how are you measuring?
<re_irc> <@c​hmanie:m​atrix.org> Hm well yeah maybe this is a schrödinger's cat type situation
<re_irc> <@c​hmanie:m​atrix.org> I was just debugging it
<re_irc> <@t​halesfragoso:m​atrix.org> 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​atrix.org> if it's on opt-level=0 this is will be way slower than expected
<re_irc> <@c​hmanie:m​atrix.org> To be honest I'm not specifying the opt-level, really
<re_irc> <@t​halesfragoso:m​atrix.org> building with `--release` ?
<re_irc> <@t​halesfragoso:m​atrix.org> 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​atrix.org> codegen-units = 1
<re_irc> <@c​hmanie:m​atrix.org> lto = true
<re_irc> <@c​hmanie:m​atrix.org> This is what I have in `[profile.release]`
<re_irc> <@c​hmanie:m​atrix.org> debug = true
<re_irc> <@t​halesfragoso:m​atrix.org> hmm release should default to opt-level = 2
<re_irc> <@t​halesfragoso:m​atrix.org> 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​atrix.org> So with opt-level="s" I'm also getting a ratio of roughly 5-10
<re_irc> <@c​hmanie:m​atrix.org> Is it the debugging instrumentation that makes it much slower?
<re_irc> <@c​hmanie:m​atrix.org> I will measure on the hardware level
<re_irc> <@c​hmanie:m​atrix.org> Thanks so far! I really appreciate it!
<re_irc> <@t​halesfragoso:m​atrix.org> @chmanie:matrix.org: if you talking about `debug = true`, no, debug information won't be flashed to the micro
<re_irc> <@c​hmanie:m​atrix.org> 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​atrix.org> Anybody tried stm32wb55 with Bluetooth
<re_irc> <@t​iwalun:m​atrix.org> @barafael:matrix.org: Yes, using https://github.com/eupn/stm32wb55
<re_irc> <@f​irefrommoonlight:m​atrix.org> Oh sweet!
<re_irc> <@f​irefrommoonlight:m​atrix.org> 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​atrix.org> Note that the NRG is much cheaper
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm adding a link to that lib in the stm32hal readme
<re_irc> <@c​hmanie:m​atrix.org> 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​atrix.org> ```rust
<re_irc> <@c​hmanie:m​atrix.org> if now == 0 {
<re_irc> <@c​hmanie:m​atrix.org> fn temp(now: u32) -> Option<[u32; 10000]> {
<re_irc> <@c​hmanie:m​atrix.org> (this is just for illustration purposes)
starblue2 has quit [Ping timeout: 272 seconds]
starblue2 has joined #rust-embedded
<re_irc> <@a​damgreig:m​atrix.org> 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​atrix.org> Urgh, this is the wrong way round, sorry
<re_irc> <@n​ewam:m​atrix.org> is there any workaround for this? Trying to get a `usize` for a pointer in const context.
<re_irc> <@n​ewam:m​atrix.org> error[E0658]: casting pointers to integers in constants is unstable
<re_irc> <@n​ewam:m​atrix.org> --> gpio/src/lib.rs:191:27
<re_irc> <@n​ewam:m​atrix.org> |
<re_irc> <@n​ewam:m​atrix.org> A workaround without using nightly that is ;)
<re_irc> <@c​hmanie:m​atrix.org> adamgreig: I meant `!=0` instead `==0`. The dip in frequency is not substantial, but it is there
<re_irc> <@c​hmanie:m​atrix.org> Compared to just returning `None`. I assume in this case it's about optimizations that can't be made
<re_irc> <@a​damgreig:m​atrix.org> When not 0 it has to set 10000 words to 100 which will take some time
<re_irc> <@a​damgreig:m​atrix.org> It's not the allocating as such (it's just on the stack) but it has to set it
<re_irc> <@c​hmanie:m​atrix.org> But shouldn't I just notice it every u32::MAX cycles?
<re_irc> <@c​hmanie:m​atrix.org> 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​atrix.org> It's not a big deal but it adds up, it seems
<re_irc> <@a​damgreig:m​atrix.org> @chmanie:matrix.org: I dunno, are you just calling it with incrementing values of now?
<re_irc> <@d​irbaio:m​atrix.org> @newam:matrix.org: don't cast to usize: `const GPIOA_BASE: *const () = pac::GPIOA::ptr() as *const ();`
<re_irc> <@d​irbaio:m​atrix.org> usize <=> ptr casts aren't allowed in const
<re_irc> <@c​hmanie:m​atrix.org> adamgreig: Yeah I increment it using an interrupt. It's too complicated right now, still, sorry. I will simplify
<re_irc> <@a​damgreig:m​atrix.org> 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​atrix.org> Thanks adamgreig I'll see if I can refactor
<re_irc> <@n​jha:o​cf.berkeley.edu> Is this still where #rust-embedded lives? Even the matrix motd says freenode 😟
<re_irc> <@t​herealprof:m​atrix.org> @njha:ocf.berkeley.edu: You came to the right place. Can you point out where you found the freenode notice?
<re_irc> <@n​jha:o​cf.berkeley.edu> Welcome to the Rust Embedded chat room! | Bridged to Freenode IRC: #rust-embedded <snip>
<re_irc> <@n​jha:o​cf.berkeley.edu> it's entirely possible this is a caching issue though
<re_irc> <@t​herealprof:m​atrix.org> Super weird. The current MOTD is: Welcome to the Rust Embedded chat room! | Discuss, coordinate, help: https://github.com/rust-embedded/wg | Code of conduct: https://www.rust-lang.org/conduct.html | Temporary bridge running to #rust-embedded on libera.chat IRC...
<re_irc> <@n​jha:o​cf.berkeley.edu> yeah probably a caching bug in synapse/element then 😐️
<re_irc> <@n​jha:o​cf.berkeley.edu> thanks!
<re_irc> <@t​herealprof:m​atrix.org> 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​atrix.org> 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​atrix.org> This is how it currently looks
<re_irc> <@s​ympatron:m​atrix.org> Can somebody here help me with a lifetime problem?
<re_irc> <@s​ympatron:m​atrix.org> 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​atrix.org> This is what I am trying to do:
<re_irc> <@s​ympatron:m​atrix.org> fn test_roundtrip<'a, T: ::serde::Serialize + ::serde::Deserialize<'a> + std::fmt::Debug + PartialEq>(value: T) {
<re_irc> <@d​irbaio:m​atrix.org> what's with the ✂️ 📝? lol
<re_irc> <@d​irbaio:m​atrix.org> sympatron: the issue is the `'a` lifetime is decided by the caller of `test_roundtrip`
<re_irc> <@d​irbaio:m​atrix.org> 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​atrix.org> 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​atrix.org> 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​atrix.org> and then it works :)
<re_irc> <@s​ympatron:m​atrix.org> 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​atrix.org> yeah it's very subtle :S
<re_irc> <@s​ympatron:m​atrix.org> 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​atrix.org> uuh
<re_irc> <@d​irbaio:m​atrix.org> fun
<re_irc> <@d​irbaio:m​atrix.org> I think the issue is
<re_irc> <@d​irbaio:m​atrix.org> you're passing a `&'a str` which gets serialized into `buf`
<re_irc> <@d​irbaio:m​atrix.org> 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​atrix.org> like, it can deserialize into &str, but not `&'a str`
<re_irc> <@d​irbaio:m​atrix.org> no idea how to fix it though
VShell has joined #rust-embedded
<re_irc> <@d​irbaio:m​atrix.org> meh.. you can workaround it by passing the buf from outside the func
<re_irc> <@d​irbaio:m​atrix.org> because you can then require the buffer is 'a too
<re_irc> <@d​irbaio:m​atrix.org> 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​atrix.org> 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​atrix.org> 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