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
bpye9 has joined #rust-embedded
bpye has quit [Ping timeout: 260 seconds]
bpye9 is now known as bpye
bpye2 has joined #rust-embedded
bpye has quit [Ping timeout: 260 seconds]
bpye2 is now known as bpye
fabic has joined #rust-embedded
Darius has joined #rust-embedded
fabic has quit [Ping timeout: 276 seconds]
diagprov has quit [Ping timeout: 260 seconds]
diagprov has joined #rust-embedded
fabic has joined #rust-embedded
emerent_ has joined #rust-embedded
emerent is now known as Guest6682
emerent_ is now known as emerent
Guest6682 has quit [Ping timeout: 248 seconds]
fabic has quit [Ping timeout: 248 seconds]
fabic has joined #rust-embedded
dc740 has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
fabic has quit [Ping timeout: 248 seconds]
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
<re_irc> <James Munns> Broad question here: Does anyone have resources (or blog posts, etc) for measuring "CPU Idle" time? Particularly in a system with interrupts (and on RTIC 1.0, if it helps), and with as little busywork as possible (e.g. not having to manually instrument all entry/exits of tasks)?
<re_irc> I _could_ do sample tracing (with ITM), or use something like rtic-scope, but ideally I'd like to also "view" the stats on-device, not just via an external debugger.
<re_irc> <James Munns> not worried about ABSOLUTE precision, e.g. +/- 1% (or even a bit more) is probably fine, but I'd prefer not to be way off in the normal cases, e.g. spending a lot of time in interrupts
<re_irc> <dirbaio> you can change your idle wfi loop to somethinglike
<re_irc> <dirbaio> interrupt::disable():
<re_irc> <dirbaio> interrupt::disable():
<re_irc> sm::wfi();
<re_irc> let start = now();
<re_irc> Idle_time += end - start;
<re_irc> let end = now();
<re_irc> <dirbaio> interrupt::disable():
<re_irc> asm::wfi();
<re_irc> let start = now();
<re_irc> let end = now();
<re_irc> <James Munns> Ah interesting. didn't realize wfi works with interrupts masked
<re_irc> <James Munns> though - I'll admit this is for "mnemos", so that's not actually possible (my "idle" loop is in unpriv space)
<re_irc> <dirbaio> heh
<re_irc> <dirbaio> make userspace measure it... or make "idle" a syscall?
<re_irc> <James Munns> Yeah, that's basically what I was thinking, make a "yield" syscall (that waits for the next hw event to occur) or change the "sleep" syscall a bit to count time spent in it (probably using something like your trick)
<re_irc> <dirbaio> (does WFI even work in unprivileged mode?)
<re_irc> <James Munns> I dunno!
<re_irc> <James Munns> (I think so tho? I know I've done it and not gotten a fault)
<re_irc> <dirbaio> maybe it just NOPs
<re_irc> <dirbaio> like disabling irqs does ☠️
<re_irc> <ryan-summers> Hey, does any know if a static ever has "drop" called on program exit?
<re_irc> <James Munns> Never, AFAIK
<re_irc> <ryan-summers> * anyone
<re_irc> <ryan-summers> That would explain why my emulated USB devices kept incrementing device numbers and eventually crashed my system... Never closed the file handle
<re_irc> <James Munns> Statics are essentially "leaked", AFAIK
<re_irc> <ryan-summers> was assuming rust's drop semantics would save me there. Not the case because it's all in a global
<re_irc> <ryan-summers> Makes sense though, thanks
<re_irc> <James Munns> If it's on a PC, you can have a signal handler
<re_irc> <James Munns> but accessing things from that context is hella cursed, IIRC
<re_irc> <ryan-summers> I already have things in a global mutex singleton, so not too bothered
<re_irc> <ryan-summers> Although I have a better idea to just manage this all better with some nicer rearchitecture
<re_irc> <ryan-summers> thanks for the intel :)
<re_irc> <James Munns> Might make sense to switch to an Arc<Mutex<>>
<re_irc> <dirbaio> when the process exits, the file descriptor should get cleaned up though
<re_irc> <dirbaio> that does close things like sockets and files
<re_irc> <ryan-summers> This is some quick and dirty hack experimentation, so eh
<re_irc> <James Munns> Yeah, though that's up to the OS how it recovers handles and such
<re_irc> <ryan-summers> It's most definitely not getting cleaned up
<re_irc> <dirbaio> that's linux's fault I'd say :D
<re_irc> <ryan-summers> It was allocating emulated USB drivers until it eventually started refusing to allocate more
<re_irc> <ryan-summers> Then it crashed my PC when I unloaded the kernel module
<re_irc> <ryan-summers> So... yay :D
<re_irc> <dirbaio> cursed
<re_irc> <James Munns> program exit (wrt static cleanups) should act equivalent to a hard abort/sigkill, basically
<re_irc> <James Munns> but yeah, if your OS is still holding the FS or whatever
<re_irc> <James Munns> or you rely on a "umount" or something in drop, that won't happen
<re_irc> <James Munns> (not sure what kind of usb devices you are emulating, disks, serial ports, etc.)
<re_irc> <James Munns> serial ports might get held by networkmanager, for example
<re_irc> <James Munns> which will ping them as modems periodically lol
<re_irc> <dirbaio> oh I hate that :D
<re_irc> <James Munns> at least it did that at some point "back in the day"
<re_irc> <dirbaio> "oh look, an UART! let's send random garbage to it just in case it's a modem, what could go wrong!"
<re_irc> <James Munns> leading to a very confused device attached to my RPi
<re_irc> <ryan-summers> In windows, if your UART port happens to send data shortly after being connected (or shortly after the PC boots) Windows will install a ball mouse driver to it
<re_irc> <ryan-summers> Which will lock up your device until you plug cycle it
<re_irc> <dirbaio> wat
<re_irc> <ryan-summers> Because apparently 90s era ball mice communicated via slow UART comms, and they keep the driver in windows for backwards compatibility
<re_irc> <ryan-summers> So you specifically have to be careful for any UARTs connected to Windows machines to hold off on transmissions or you risk WIndows taking over the device as a ball mouse
<re_irc> <ryan-summers> Or you can disable the ball mouse driver
<re_irc> <ryan-summers> It's another one of those cursed things that I had the privilege of learning :)
<re_irc> <ryan-summers> This is sometimes why troubleshooting guides recommend plug cycling devices
<re_irc> <TimSmall> James Munns dirbaio That's ModemManager rather than NetworkManager I think. Auto-probe behaviour is distro-specific, and controlled with udev-rules. These days (at least with the distros I've used), device probing is opt-in for auto-probing, and even for manual scanning (on Debian etc. "/lib/udev/rules.d/77-mm-usb-serial-adapters-greylist.rules").
<re_irc> <dirbaio> yeah, it was ModemManager on Arch a while ago
<re_irc> <dirbaio> dunno if it's fixed, I simply uninstalled it 😂
<re_irc> <dirbaio> yeah, it was ModemManager on Arch, 2-3 yearsago
<re_irc> <dirbaio> yeah, it was ModemManager on Arch, 2-3 years ago
<re_irc> <wembly> i just got a pyportal to play with embedded rust, and i'm kinda struggling with some what i'm assuming are basic concepts, i can't figure out why i can't get the neopixel to change colors
<re_irc> <wembly> i've basically combined the two examples in the bsp, (blinkie and neopixel) and it's just displaying white on the neopixel
<re_irc> <wembly> i've also tried slowing the timer down from 3mhz to 30mhz without any change
dc740 has quit [Remote host closed the connection]
Foxyloxy has quit [Ping timeout: 276 seconds]
<re_irc> <wembly> also does anyone have anything slightly more complex than the examples that are in the atsamd hal board bsp examples dir?
fabic has joined #rust-embedded