ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
glitchy has joined #rust-embedded
Pete[m]1 has quit [Quit: Idle timeout reached: 172800s]
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
glitchy has quit [Remote host closed the connection]
glitchy has joined #rust-embedded
ska has quit [Ping timeout: 252 seconds]
GuineaWheek[m] has quit [Quit: Idle timeout reached: 172800s]
ska has joined #rust-embedded
cbjamo[m] has joined #rust-embedded
<cbjamo[m]> diondokter: I just used device-driver for the first time. It's awesome, so much nicer to write than what I've done with bitfield libs and device-register in the past.
<cbjamo[m]> I used the yaml interface. The only hiccup I had was that I couldn't name enum variants "_<number>" like I'd do if hand writing. I went with "n_<number>" instead. That change isn't a big deal by itself, but the error message was fairly unhelpful. I suppose that might just go away in the switch to kdl.
<cbjamo[m]> The driver is for work, so there's a process before I can open source the driver, but it should be eventually.
diondokter[m] has joined #rust-embedded
<diondokter[m]> <cbjamo[m]> diondokter: I just used device-driver for the first time. It's awesome, so much nicer to write than what I've done with bitfield libs and device-register in the past....... (full message at <https://catircservices.org/_irc/v1/media/download/AW-0LpBQIh3_8tto2EX83zhwmuUgsH4f7F4Sg3l4JnyS3rrcgqpckkuQA8RAXtHFgHC4xab_ESJ_CcJEMskXPBu_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9XblFDSWRKUlBhY2dBa1ZvcEtWZE9Pc2w>)
<cbjamo[m]> Most of the errors I got were very good. Rust still told me that it was an enum variant issue, but that error didn't give me a line number. Because "_1" is a valid name in rust it took me a little bit to put together that was the problem. My guess is that something in the yaml parsing stripped the _, so rust saw just "1".
<diondokter[m]> Issue so I don't forget
<diondokter[m]> cbjamo[m]: Ah, the curse of yaml probably yeah. KDL is much better
kenny has quit [Ping timeout: 252 seconds]
kenny has joined #rust-embedded
RobinMueller[m] has quit [Quit: Idle timeout reached: 172800s]
Lumpio[m] has quit [Quit: Idle timeout reached: 172800s]
starblue has joined #rust-embedded
_whitelogger has joined #rust-embedded
RobWells[m] has quit [Quit: Idle timeout reached: 172800s]
sroemer has quit [Quit: WeeChat 4.5.2]
khionu[m] has joined #rust-embedded
<khionu[m]> For memory.x files, the ORIGIN is the numerically-high end of the address range, right?
<khionu[m]> Or... hrmm, less certain now
<khionu[m]> I'm adding embassy-boot to the mix, so I'm defining this by hand for the first time
<dirbaio[m]> ORIGIN is the start address (so lowest)
<khionu[m]> Alrighty, thanks
andar1an has joined #rust-embedded
glitchy has quit [Remote host closed the connection]
glitchy has joined #rust-embedded
ska has quit [Quit: Leaving]
andar1an has quit [Quit: andar1an]
everdrone[m] has joined #rust-embedded
<dngrs[m]> if something stops working you've got either a compiler bug or, more likely, a piece of code that's not as identical as you think it is
<dngrs[m]> * as identical to the working one as you
<everdrone[m]> The only thing that's changing is #[inline(never)] on set_low
<everdrone[m]> The only other thing that makes it work without the inline hint is using if matches!(self.communication_speed, Speed::HighSpeed) { ... } else { ... } instead of the match statement. The instructions inside the curly braces are identical.
<dngrs[m]> does Speed only have the variants HighSpeed and Standard?
<everdrone[m]> Yes
<everdrone[m]> I even tried putting compiler fences (without any luck). Feels like I'm not in control of the order of the instructions at this point
<dngrs[m]> ok. I still don't think your observation matches what actually happens. rustc does not switch instructions around arbitrarily. Do you have interrupts or other stuff that could interfere?
<dngrs[m]> my gut feeling is you might sometimes run into error conditions and your question marks then bail out early
<dngrs[m]> I'd suggest adding some logging.
<everdrone[m]> No interrupts, this code runs in the init function in rtic. And on top of that, I don't see how interrupts could interfere only when not inlining a function
<everdrone[m]> dngrs[m]: I tried many times in both cases and the eeprom Nacks always when not using #[inline(never)]
<dngrs[m]> inlining or changing the opt level will influence one thing primarily and that is timing
<dngrs[m]> that's all I can tell you without the device in front of me
<dngrs[m]> maybe some method fails when you're juuuust missing a leading or trailing edge, or something along those lines.
<everdrone[m]> But how would inlining a function mess with the timing on the order of microseconds? the mcu runs at 72MHz
<dngrs[m]> all I'm saying is a compiler bug is pretty unlikely
<dngrs[m]> build a simulation environment suitable for running your code
<dngrs[m]> I'd be very surprised if you'd see the change in behavior between (no) inlining and matches!
<everdrone[m]> I suspect that logging statements with defmt will realign the instructions, so it will only fail in release mode where defmt calls are stripped away
<everdrone[m]> But I'll start there for now
<everdrone[m]> thanks
<dngrs[m]> defmt can introduce pretty big slowdownsa
<dngrs[m]> s/slowdownsa/slowdowns/
<dngrs[m]> in general though building in debug mode is too slow for timing sensitive embedded Rust scenarios
<dngrs[m]> * slow for many timing sensitive
<everdrone[m]> Yeah, my concern is more about how the compiler will not reorder things once defmt is placed in between calls here and there
<dngrs[m]> the compiler does not randomly reorder stuff
<everdrone[m]> dngrs[m]: well, not randomly but it does reorder stuff, otherwise what is the purpose of `compiler_fence`?
<dngrs[m]> at least it will not reorder changing semantics
<dngrs[m]> if you need a fence in debug mode you need it in release mode
<everdrone[m]> debug mode is almost identical to release mode, with the exception of symbols and defmt being disabled completely in release mode
<dngrs[m]> if you have no interrupts and only one core, afaik you don't need fences
<dngrs[m]> everdrone[m]: again: timing
<dngrs[m]> debug builds are slow
<dngrs[m]> defmt too
<dngrs[m]> I have personally run into timing issues when logging a lot with defmt
<everdrone[m]> dngrs[m]: Yeah it messes up the audio applications if put anywhere near audio buffer operations
<everdrone[m]> Also, using delay.delay_us(2) instead of 1 on tLOW1 (High Speed) makes the eeprom respond again..
<everdrone[m]> I wonder if it's the pull-up resistor that messes up the reading at this point
<dngrs[m]> really, for anything timing sensitive I'd advise to entirely avoid debug builds. It's not like you actually get any meaningful debuggability from them ...