<re_irc>
<dirbaio> maybe llvm has folded identical funcs and gdb has picked the wrong one
<re_irc>
<dirbaio> or some other optimization shenanigan
<re_irc>
<dirbaio> :(
<re_irc>
<adamgreig> presumably it worked before i changed to stable asm!() too though, so...
<re_irc>
<adamgreig> it panics even if I remove the write!(), just unwrappnig hstdout?
skunkjoe has quit [Ping timeout: 240 seconds]
<re_irc>
<adamgreig> if I replace the panic_halt with a custom panic handler that just does semihosting exit EXIT_SUCCESS/EXIT_FAILURE, I get the respective exit code, so... it's definitely panicking trying to stdout(), heh
<re_irc>
<almindor> do we have a standard way to handle "optional" resources? e.g. say you have a "Option<X: OutputPin>" kind of thing in your struct. The "None" case then makes the type somewhat moot but it still has to be specified. Should I just make an internal hidden dummy for that case?
<re_irc>
<dirbaio> "Option<T>" is annoying because even if you pass None, you have to specify the type
<re_irc>
<almindor> yes that's my point, I can do something like my own dummy type for the "T" trait constraint, but I'm wondering if we might have a more standard approach to this
<re_irc>
<dirbaio> maybe you can do "new(...) -> Self<DummyPin>", "new_with_rst(..., rst: T) -> Self<T>"?
<re_irc>
<almindor> yes, I'm just curious if I should make my own dummy pin :D
<re_irc>
<dirbaio> maybe
<re_irc>
<dirbaio> * that'd work
<re_irc>
<dirbaio> or maybe you could do your own OptionalPin trait
<re_irc>
<dirbaio> not sure if that would cause conflicting impls
<re_irc>
<almindor> you mean if I "impl<X> OptionalPin for X: OutputPin" kind of thing as well..
<re_irc>
<adamgreig> ugh, I'm stumped, it seems like qemu is saying "error" when rust makes the semihosting syscall from release mode but not from debug mode, but... what's the difference
<re_irc>
<dirbaio> asm getting optimized wrong?
<re_irc>
<adamgreig> looks _ok_ from a glance
<re_irc>
<adamgreig> hard to tell though
<re_irc>
<adamgreig> it passes a pointer to a string ":tt\0" when opening stdout, I wonder if the string is getting eaten somehow
<re_irc>
<adamgreig> wish it were easier to debug what's being pased to qemu, heh
<re_irc>
<adamgreig> hstdout() calls open(":tt\0"), open does name.as_bytes().as_ptr() and passes the ptr to syscall!() which calls syscall1 which calls cortex_m::asm::semihosting_syscall()
<re_irc>
<adamgreig> if cortex_m::asm::semihosting_syscall is inline, it goes wrong, but if it's inline(never), it's OK
<re_irc>
<dirbaio> ah other syscalls might write yep
<re_irc>
<adamgreig> or, rather, semihosting can
<re_irc>
<dirbaio> this particular one shouldn't
<re_irc>
<adamgreig> open() call won't, but the cortex_m::asm::semihosting_syscall() definitely could
<re_irc>
<dirbaio> one asm block per syscall with the right flags could allow better optimizations
<re_irc>
<dirbaio> semihosting is slow as hell anyway
<re_irc>
<dirbaio> so probably not worth it :D
<re_irc>
<adamgreig> all it's going to do is let llvm delete more things you don't want it to, i bet
<re_irc>
<dirbaio> 😂
<re_irc>
<adamgreig> let's see if that's enough to sate the CI gods
<re_irc>
<adamgreig> yay it's green
<re_irc>
<dirbaio> is there a wishlist of stuff for 0.8?
<re_irc>
<dirbaio> +breaking changes
<re_irc>
<dirbaio> I'd love a way to remove the default hardfault trampoline
<re_irc>
<dirbaio> had to do some ugly hacks
<re_irc>
<adamgreig> that's cortex-m-rt, not related
<re_irc>
<adamgreig> not sure if it will be 0.8 or a 0.7 patch since the inline asm is only visible as a bump to msrv
<re_irc>
<adamgreig> but certainly i'm interested in resolving that, sure
<re_irc>
<adamgreig> maybe it will be easier with inline asm too
<re_irc>
<adamgreig> since we can just not emit it, or emit an empty one or whatever
<re_irc>
<adamgreig> if you have any ideas I'd have a go now in this PR
<re_irc>
<James Munns> So, half-thought here
<re_irc>
<James Munns> would inline asm help anything in PAC/svd2rust land?
<re_irc>
<James Munns> I don't think it would, at least not with the current vcell usage (is that already addressed to handle the theoretical "dereferenceable" UB?)
<re_irc>
<adamgreig> svd2rust still has that theoretical issue
<re_irc>
<adamgreig> i had wondered if you could use inline asm to do some neat workaround but i think at the end of the day nothing you couldn't have accomplished with an AtomicU32 or whatever
<re_irc>
<adamgreig> you could implement write_volatile in terms of asm!() but why would you
<re_irc>
<dirbaio> I don't think svd2rust is fixable with the current "make a struct whose field layout matches the regblock"
<re_irc>
<dirbaio> +method
<re_irc>
<adamgreig> well, you could keep that, the important thing is to not make a memory mapped reference to it
<re_irc>
<dirbaio> why'd you do the "struct with matching layout" thing then?
<re_irc>
<adamgreig> there's probably no particular need to make it match the memory layout.. maybe you could use addr_of!() for convenience of getting offsets?
<re_irc>
<adamgreig> not saying you'd have to, but that's not the problem with it
<re_irc>
<dirbaio> I mean, if you're not going to cast a regblock ptr to a struct ptr, then there's no point in making the struct match layout
<re_irc>
<James Munns> I think Rust has offset_of these days :p
<re_irc>
<adamgreig> it might be a convenient way to get the offsets of each field, dunno
<re_irc>
<adamgreig> does it? there's addr_of but i think you need to go to a crate for offset_of?
<re_irc>
<adamgreig> bytemuck maybe
<re_irc>
<James Munns> Oh, for some reason I thought there was one added, but I don't see it
<re_irc>
<adamgreig> also memoffset crate has it
<re_irc>
<adamgreig> but yea, maybe you instead have a function that encodes the offset when you write it, whatever
<re_irc>
<dirbaio> from the svd you already know the offsets
<re_irc>
<adamgreig> probably simpler than having the struct layout be correct in memory
<re_irc>
<adamgreig> sure, of course we know them, it's just a question of how you encode that knowledge in the PAC
<re_irc>
<adamgreig> you encode them as literals in the method you have for each field, but there are other ways, like having fields on a struct and using offset_of!()
<re_irc>
<adamgreig> I'm just spitballing one possible reason to keep the laid-out structs, not trying to defend what's probably a bad idea
<re_irc>
<dirbaio> struct fields have some problems:
<re_irc>
- you can't have two regs at the same addr
<re_irc>
- you can't make "interleaved arrays": if a regblock is "[A0, B0, A1, B1, A2, B2...]" you can't make two arrays A[] and B[] out of it
<re_irc>
<dirbaio> and the code to generate them is quite complex, it has to sort, check for overlaps, then emit the fields in order, emitting dummy fields for padding...
<re_irc>
<James Munns> (didn't mean to start a war, btw)
<re_irc>
<James Munns> Deleted what was now a poorly timed joke.
<re_irc>
But I didn't mean to start a fight about svd2rust :p
<re_irc>
<dirbaio> it's not a fight lol
<re_irc>
<James Munns> :D
<re_irc>
<James Munns> (hi, i'm james, and i'm conflict averse, have you met me?)
<re_irc>
<pyaillet> dirbaio: Just for my own curiosity, what is the benefit of defining an internal trait rather than relying on the already existing one ?
<re_irc>
<pyaillet> * OutputPin directly
<re_irc>
<laizy> Hi, all. I want to compile a crate to riscv32 with ima feature and without compressed instructions. Currently, rustc only provide the following targets:
<re_irc>
<9names (@9names:matrix.org)> great! i wasn't super confident, i don't know how much folks test around all the extensions
<re_irc>
<9names (@9names:matrix.org)> was half expecting it to still have some C instructions coming from somewhere
Guest2 has joined #rust-embedded
tokomak has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 240 seconds]
crabbedhaloablut has joined #rust-embedded
tokomak has quit [Ping timeout: 240 seconds]
jringstad__ has joined #rust-embedded
Amadiro has quit [Ping timeout: 245 seconds]
ymwm has joined #rust-embedded
jackneillll has quit [Quit: Leaving]
jackneill has joined #rust-embedded
ymwm has quit [Ping timeout: 272 seconds]
jasperw has quit [Ping timeout: 256 seconds]
ymwm has joined #rust-embedded
ymwm has quit [Max SendQ exceeded]
ymwm has joined #rust-embedded
jasperw has joined #rust-embedded
ymwm has quit [Quit: Leaving]
ymwm has joined #rust-embedded
Guest2 has quit [Ping timeout: 256 seconds]
ymwm has quit [Ping timeout: 256 seconds]
crabbedhaloablut has quit [Ping timeout: 240 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<almindor> does anyone else using Vscode + rust-analyzer get recompile competition between the IDE and outside? e.g. if I change something, the IDE cargo checks stuff, but then if I "cargo build" the build always seems to re-build everything. And then if I change something in the IDE and save the IDE has to rebuild everything again. I'm sure it's some sort of odd target/setup diff but I can't find out what
<re_irc>
<almindor> only happens on my embedded projects
<re_irc>
<mygnu> Didn’t the latest compiler turned off the incremental compilation by default?
<re_irc>
<dirbaio> make sure you have the target set in .vscode/settings.json (though I think i should pick it up from .cargo/config.toml?)
<re_irc>
<dirbaio> could also be due to different features, rustflags..
<re_irc>
<dirbaio> I had it happen with DEFMT_LOG too
<re_irc>
<almindor> hmm I'm using a workspace that has projects with differing targets, I guess I need to have a .vscode/settings.json for each then?
<re_irc>
<dirbaio> as a workaround you can make cargo use a different target dir: "CARGO_TARGET_DIR=target2 cargo build ..."
<re_irc>
<almindor> the only thing I have on the top level tho is ``` "rust-analyzer.checkOnSave.allTargets": false
<re_irc>
<dirbaio> then open that in vscode, instead of "open folder"
<re_irc>
<dirbaio> so you can specify the exact crate, target, features... for the exact thing you're going to work on
<re_irc>
<almindor> how do you handle dependency overrides without cargo workspaces tho?
<re_irc>
<dirbaio> you can put them in the "main" crate's Cargo.toml
<re_irc>
<dirbaio> that means you might have to duplicate them, yes..
<re_irc>
<dirbaio> maybe you can do the .code-workspace thing while still keeping the Cargo workspace in your case
<re_irc>
<dirbaio> with mixing targets it's usually troublesome, it'll try to build all the crates so you'll get tons of errors from the crates with the "wrong" target
<re_irc>
<almindor> hmm yeah it seems forcing one target on the whole thing works in my case. The only other target I had was in an example so it ignores that until I open it up
<re_irc>
<dngrs (spookyvision@github)> I have a USB UART running on STM32F411. When I send data to the mcu over a certain rate, the world seems to stop - I don't even get defmt log updates that I put in the usb interrupt handler. What's going on here, is the ISR running at such a high priority that nothing else gets done? This problem gives me terrible latency with all tasks that process the incoming data, of course
<re_irc>
<dngrs (spookyvision@github)> I've tried to move all processing from the ISR to a (RTIC) software task but that didn't solve the problem either
<re_irc>
<henrik_alser> dngrs (spookyvisiongithub): Hmm, what rate?
<re_irc>
<dngrs (spookyvision@github)> henrik_alser: I haven't measured it yet but it's just me moving a midi controller slider on the host, which then gets serialized via postcard, so it can't be a LOT
<re_irc>
<dngrs (spookyvision@github)> I'm gonna toggle a board led on usb interrupt to see if part of my problem is just defmt running at too low prio (I do however experience the lags later on ... hmm, actually - gonna try and up the priority on the DMX tasks)
<re_irc>
<henrik_alser> Ahh is it an interrupt or a bulk transfer?
<re_irc>
<firefrommoonlight> dngrs (spookyvision@github): Let's rule out a near miss with a black hole or brown dwarf, and go straight to the psychological explanation
<re_irc>
<firefrommoonlight> You're in love
<re_irc>
<dirbaio> 🤔 😂
<re_irc>
<dngrs (spookyvision@github)> henrik_alser: whatever the OS does 🤷
<re_irc>
<dngrs (spookyvision@github)> I always assume bulk tho
<re_irc>
<henrik_alser> I mean midi is usually transferred as interrupt no?
<re_irc>
<henrik_alser> Oh but you dont actually send midi?
<re_irc>
<dngrs (spookyvision@github)> I'm sending serialized (:D) MIDI data over usb-serial
<re_irc>
<henrik_alser> Ahh got it
<re_irc>
<henrik_alser> Then bulk
<re_irc>
<dngrs (spookyvision@github)> on the host side there are no delays at least up until the serial port is filled, I can see that in the logs
<re_irc>
<henrik_alser> What baud do you use on the host?
<re_irc>
<henrik_alser> Yes but seems to make a difference in my experience
<re_irc>
<dngrs (spookyvision@github)> mhk - anyway I can't midi THAT fast
<re_irc>
<dngrs (spookyvision@github)> I'm thinking it must be some kind of priority inversion or whatever going on - I turn the incoming data into DMX commands which get sent out via DMA and that's where I first observed the lag, then I put the logs in and saw they freeze too
<re_irc>
<dngrs (spookyvision@github)> gimme a sec to get the LED flashing thing going
<re_irc>
<dngrs (spookyvision@github)> to rule out at least the aspect that defmt just gets no chance to run because the usb interrupt keeps firing
<re_irc>
<henrik_alser> No hmm, i’ve been dumping huge amounts of data like that without issues
<re_irc>
<henrik_alser> But i usually do it in chunks
<re_irc>
<dngrs (spookyvision@github)> yeah it must be something silly I'm not doing right
<re_irc>
<dngrs (spookyvision@github)> just wondering what the hell
<re_irc>
<henrik_alser> Yeah…
tokomak has joined #rust-embedded
<re_irc>
<dngrs (spookyvision@github)> yeah, it doesn't flash when I'm doing a continuous slider motion
<re_irc>
<dngrs (spookyvision@github)> the handler is at the bottom
skunkjoe has joined #rust-embedded
<re_irc>
<dngrs (spookyvision@github)> I wonder if there's some buffering on the host side going on¿¿
<re_irc>
<dngrs (spookyvision@github)> I guess that must be it; a quick test on the shell gives me rapid flickering
<re_irc>
while sleep 0.001; do echo AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > /dev/cu.usbmodemMDSA8059151; done
<re_irc>
<dngrs (spookyvision@github)> yeah, it' s the server code after all
<re_irc>
<dngrs (spookyvision@github)> insert long list of swear words here
<re_irc>
<dngrs (spookyvision@github)> serves me right for using this fancy new async stuff with a gorillion queues and tasks
<re_irc>
<dngrs (spookyvision@github)> sigh, and what do I find in the server code at approximately the right place ... "// TODO bottleneck!"
<re_irc>
<dngrs (spookyvision@github)> well done, past me
<re_irc>
<monacoprinsen> Hey guys,
<re_irc>
I just talked to a guy from Espressif regarding a lack of Bluetooth support for Rust on the Esp32 at this moment.
<re_irc>
He said that if we raised this topic and there was a demand they would prioritize to add the Bluetooth functionality.
<re_irc>
I just opened an issue for the lack of Bluetooth support.
<re_irc>
<henrik_alser> dngrs (spookyvisiongithub): What kind of server is that?
<re_irc>
<dngrs (spookyvision@github)> ooh, nice
<re_irc>
<dngrs (spookyvision@github)> henrik_alser: something like MQTT but with a lot of internal logic. I'm building a "synchronize ALL the media" kind of thing, where you can, for example, make some DMX fixture light up exactly when the DJ deck passes a beat bar. Or draw something with a laser to the beat, etc
<re_irc>
<henrik_alser> Yay!
<re_irc>
<dngrs (spookyvision@github)> definitely gonna show it off when it's more ready, heh. I do have an old video somewhere though ....
<re_irc>
<henrik_alser> So that part is not your own i mean?
<re_irc>
<henrik_alser> How is your midi controller connected to this?
<re_irc>
<dngrs (spookyvision@github)> henrik_alser: it is my own, I'm writing all the things
<re_irc>
<dngrs (spookyvision@github)> the web frontend uses the same LED rendering code as the mcu, thanks to webassembly and some clever glue code (like, 20 lines? Rust is the future)
<re_irc>
<dngrs (spookyvision@github)> henrik_alser: via a usb-midi callback in the server. But! you can also send it midi events over a virtual port, which is exactly how the dj software syncs up
<re_irc>
<dngrs (spookyvision@github)> or completely synthetic, over websockets
<re_irc>
<dngrs (spookyvision@github)> which is what I most of the time do because DJing and writing software _at the same time_ isn't fun
<re_irc>
<henrik_alser> Nice!
<re_irc>
<dngrs (spookyvision@github)> I -am- pretty proud of it
<re_irc>
<dngrs (spookyvision@github)> one day it will even be done!
<re_irc>
<henrik_alser> Ahh i thought you meant that TODO was out of your control :)
<re_irc>
<dngrs (spookyvision@github)> past me wrote that and immediately evicted that fact from memory
<re_irc>
<dirbaio> so cool 🤩
<re_irc>
<dngrs (spookyvision@github)> I am rather annoyed with the state of light shows in clubs. They're almost never synchronized! Even at expensive/special events. I _really_ wonder why that is
<re_irc>
<henrik_alser> Yeah
<re_irc>
<dngrs (spookyvision@github)> anyway, since I concluded there was no such thing I set off to write my own, and then a year later found that Pioneer of course does have some rather sophisticated software to do that.
<re_irc>
<dngrs (spookyvision@github)> _now_ I wonder why nobody seems to _use_ it
<re_irc>
<dngrs (spookyvision@github)> my theory is that sound people just don't talk to light people in general
<re_irc>
<henrik_alser> dngrs (spookyvision@github): This is true
<re_irc>
<henrik_alser> (I’m an audio engineer)
<re_irc>
<henrik_alser> Lol
<re_irc>
<dngrs (spookyvision@github)> anyway, my goal is that I can give the DJ a USB dongle that has one DMX out and a few other outs and it's just get sync signal, fire and forget
<re_irc>
<dngrs (spookyvision@github)> (unfortunately pioneer is a walled garden and doesn't speak midi clock but hey, _just another protocol to implement_)
<re_irc>
<henrik_alser> Did a recording of a Kraftwerk show a cpl years ago and they had it all figured out of course, they used a SMPTE channel
<re_irc>
<dngrs (spookyvision@github)> there are a few such acts, daft punk shows also very well synchronized
<re_irc>
<dngrs (spookyvision@github)> definitely the minority though
<re_irc>
<dngrs (spookyvision@github)> and it _offends_ me
<re_irc>
<dngrs (spookyvision@github)> (that there aren't more)
<re_irc>
<henrik_alser> Yes i’ve been recording shows with every band of that scale and everything is surprisingly manual
<re_irc>
<henrik_alser> Also props to the Kraftwerk crew for their dress code with press fold pants and jackets labled Chernobyl
<re_irc>
<dngrs (spookyvision@github)> ha, nice :D
<re_irc>
<henrik_alser> Haha!
<re_irc>
<henrik_alser> Also handed out like 30 000 pairs of 3D glasses of course
<re_irc>
<dngrs (spookyvision@github)> ___
<re_irc>
<dngrs (spookyvision@github)> * "*_*"
<re_irc>
<dngrs (spookyvision@github)> oh btw, gonna show you something, you'll probably get a kick out of this
<re_irc>
<dngrs (spookyvision@github)> What I needed: A DMX terminator
<re_irc>
<dngrs (spookyvision@github)> what I had: resistors, pieces of solder and hot glue
<re_irc>
<dirbaio> wtf? 🤣
<re_irc>
<dngrs (spookyvision@github)> yeah, I know what you're thinking: why the pieces of solder? but they're the exact right diameter, unlike the resistor wires
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 240 seconds]
<re_irc>
<9names (@9names:matrix.org)> Fluxless solder or did you just YOLO it?
<re_irc>
<dngrs (spookyvision@github)> little flux. Should probably clean that I guess
<re_irc>
<henrik_alser> dngrs (spookyvision@github): Love it!
<re_irc>
<henrik_alser> Anyone remembers the tv show McGuyver?
<re_irc>
<dngrs (spookyvision@github)> henrik_alser: I should sell it as a limited edition
<re_irc>
<dngrs (spookyvision@github)> henrik_alser: sure do 👴
<re_irc>
<henrik_alser> dngrs (spookyvision@github): Same energy
<re_irc>
<dngrs (spookyvision@github)> before mp3 players really were a thing I bought a very experimental board that could decode mp3s ... I had no case so I cut one out of an old pack of ice tea
<re_irc>
<dngrs (spookyvision@github)> (I'll never do that again)
<re_irc>
<henrik_alser> Solid!
<re_irc>
<dngrs (spookyvision@github)> that's exactly what it wasn't
<re_irc>
<dngrs (spookyvision@github)> it did, however, make for a poor air freshener substitute. Turns out tetra pak is rather hard to clean thoroughly (or maybe I just didn't?) so my car was _very peachy_ for quite a while
<re_irc>
<henrik_alser> Genius
<re_irc>
<dngrs (spookyvision@github)> I do what I can