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.
<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".
<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]: 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 ...