Mathias[m] has quit [Quit: Idle timeout reached: 172800s]
sroemer has joined #rust-embedded
pcs38 has joined #rust-embedded
wassasin[m] has joined #rust-embedded
<wassasin[m]>
TIL you need LTO to get rid of panic data in .rodata
Foxyloxy has quit [Read error: Connection reset by peer]
Foxyloxy has joined #rust-embedded
RobinMueller[m] has quit [Quit: Idle timeout reached: 172800s]
davidmpye[m] has joined #rust-embedded
<davidmpye[m]>
I think I'm getting into an SPI mess - and wonder if anyone can help. I am using the MFRC522 driver crate, and you can create an Spi ExclusiveDevice and use that to create the driver, then call init() on it. If you want to destroy the driver, and get the interface back, there is a release() which does that for you. However, if the driver fails to init, it gives you an error back, and the interface is forever lost. Is this a
<davidmpye[m]>
common driver pattern?
<dirbaio[m]>
create the driver with `&mut` on the SPI
<dirbaio[m]>
* with `&mut ExclusiveDevice`
<dirbaio[m]>
`SpiDevice` has a blanket impl for `&mut T`
<davidmpye[m]>
The driver insists on taking the ExclusiveDevice and not a reference for it, unless I am missing something
<dirbaio[m]>
due to the blanket impl, anywhere you can pass an `ExclusiveDevice` you can also pass a `&mut ExclusiveDevice`
<dirbaio[m]>
with `&mut` you can simply drop the driver anytime which releases the borrow
<dirbaio[m]>
* the borrow and you can use the spi again
<davidmpye[m]>
Yass! That does it
<davidmpye[m]>
Thank you!
jason-kairos[m] has quit [Quit: Idle timeout reached: 172800s]
AlexandervanSaas has joined #rust-embedded
<AlexandervanSaas>
I have some sensor data that I log out using defmt and read on the host using probe-rs and I'm looking for a way to make live plots of this data. I know this type of thing is typically done by outputting the data over serial and using a serial monitor like SerialStudio but using defmt and probe-rs seems much more convenient, if I can get the raw values. Is this something people have tried before? probe-run used to have a
<AlexandervanSaas>
--json option to output structured data from defmt-decode but probe-rs doesn't have this option it seems. Would adding this be the first step in getting this to work? Or is there some other way to get the decoded but not string formatted defmt frames?
<dirbaio[m]>
i've done this by piping probe-rs to a terrible terrible python script that parses the logs back from text :D
<dirbaio[m]>
if log line matches some regex parse floats out of it, if not print it to stdout so you can still see all non-plot logs 🤣
<AlexandervanSaas>
ah yes that should work too
dngrs[m] has joined #rust-embedded
<dngrs[m]>
AlexandervanSaas: what I've done is to send both defmt and sensor data using `defmt-bbq`
<Ralph[m]>
AlexandervanSaas: did you consider using `postcard-rpc` instead for transmitting the data?
<AlexandervanSaas>
Ralph[m]: I kinda like the default defmt/probe-rs setup and rather not add any extra code for this on the target.
<Ralph[m]>
AlexandervanSaas: i get your point. just wanted to make sure that you're aware of the fact that there's a neat tool in the toolbox to transmit data in an efficient manner between the target & host which is completely decoupled from logging.
<dngrs[m]>
imo it's better to keep logs and other (e.g. time series) data separate, otherwise you'll either need annoying special case handling to filter out what you wanna plot
<AlexandervanSaas>
Ralph[m]: Yeah I've used postcard rps before :) In this case I just want to get some intuitive sense of the sensor values, the plotting is not part of the project itself. If I can get this working I liek that I can log stuff from different tasks and figure it all out on the host.
<AlexandervanSaas>
* Yeah I've used postcard-rpc before :) In this case I just want to get some intuitive sense of the sensor values, the plotting is not part of the project itself. If I can get this working I like that I can log stuff from different tasks and figure it all out on the host.
<AlexandervanSaas>
dngrs[m]: Yeah if plotting data is the goal of the project I fully agree.
<dngrs[m]>
I mean that's what you asked about ...
<dngrs[m]>
but even if you just want to store it, you still need to filter out non-"data" log messages
<dngrs[m]>
I need to leave now but I'll link something specific when I'm back, it's not hard to set up defmt-bbq instead to do this separation for you
<AlexandervanSaas>
I checked and the JSON format output by defmt-decoder contains the already formatted log string so adding JSON output to probe-rs wouldn't help much compared to parsing the existing output.
TomB[m] has joined #rust-embedded
<TomB[m]>
why the heck with -Zfmt-debug=none do I still see core::fmt:: calls, painful
<TomB[m]>
just trying to do a little tinkering, but the ELF bloat from fmt is wild
<dirbaio[m]>
> fmt-debug=val -- how detailed `#[derive(Debug)]` should be. `full` prints types recursively, `shallow` prints only type names, `none` prints nothing and disables `{:?}`. (default: `full`)
<dirbaio[m]>
that's not guaranteed to completely disable core::fmt.
<dirbaio[m]>
it just makes derive'd debugs do nothing.
<AlexandervanSaas>
In case someone else find this looking for a hacky solution: Serial Studio supports reading data from a TCP socket so I wrote a small program that sets up a TCP lisnener, parses the probe-rs output using some ugly regex generated by chatgpt and pushes it to the stream. It's not pretty and not very reusable but it works 🤷
<dirbaio[m]>
is it a firmware? why build for linux?
<TomB[m]>
its a no_std lib, but could be useful on linux or embedded situations
<TomB[m]>
but yeah this doesn't give me lots of hope when I'm doing all the tricks and still see ipv6 formatting without touching core::net at all
<dirbaio[m]>
ah it's a lib?
<dirbaio[m]>
not a bin?
<dirbaio[m]>
I don't think cargo bloat is usable with libs?
<dirbaio[m]>
dead-code elimination is only done when doing the final linking to obtain a binary
<TomB[m]>
hmmm ok will try with a sample app using the lib then, maybe that's the issue, tried doing this by building as a dylib
<TomB[m]>
because as you noted, cargo bloat didn't like the static lib
<dirbaio[m]>
if it's a rust lib you can't measure it as staticlib or dylib, it's simply measuring the wrong thing
<dirbaio[m]>
it only makes sense if you're going to statically link it (staticlib) or dynamically load it (dylib) into C projects
<dirbaio[m]>
for dylibs there's -Zdefault-visibility=hidden, it'll optimize out everything not reachable from #[no_mangle] extern "C" fns
<dirbaio[m]>
(why it's not the default is beyond me lol. I had insane bloat due to this when building for android jni lib)
FreeKill[m] has joined #rust-embedded
<FreeKill[m]>
QQ - Has anyone used postcard-rpc with RTT as the transport? I assume it's possible...?
<dirbaio[m]>
but if it's a rust lib the only way to reliably measure it is actually building a binary.
<TomB[m]>
right on, will try some more stuff tomorrow I guess
<TomB[m]>
I do want to build very specially crafted elf files at some point, but... for another day
sroemer has quit [Quit: WeeChat 4.5.2]
<JamesMunns[m]>
<FreeKill[m]> "QQ - Has anyone used postcard-..." <- I have a poc, it’s not prod ready, but should be usable, would be happy to have more hands helping to get it polished and merged
<FreeKill[m]>
Nice! I'm wondering how much of the way to a SystemView like backend we are with just that 👀
<JamesMunns[m]>
JamesMunns[m]: Note the open issues, you definitely want to use the newest probers crate, there have been some important rtt fixes
<JamesMunns[m]>
FreeKill[m]: embassy also has an rtos-trace feature that makes systemview observability work iirc, haven’t used it personally. Not sure how easy it would be to use both at the same time, but they could be on different rtt channels
<FreeKill[m]>
Ah very cool
<FreeKill[m]>
The problem of course is that SystemView is licensed software :P
<FreeKill[m]>
Using it in a company setting is expensive :c
<JamesMunns[m]>
I built a very silly version dumping trace data over usb using prpc, it was good for testing, but required a lot of buffer space to handle bursts
<JamesMunns[m]>
I was doing very silly stress test things tho, it might fair better under reasonable load
<FreeKill[m]>
native systemview struggles under bursts too 🤷
<JamesMunns[m]>
Fair :D
<JamesMunns[m]>
I was also using usb-fs, tho that should be competitive bandwidth wise with a decently fast swd debugger
<JamesMunns[m]>
(Esp if your swd debugger is also usb fs, Like a pico probe or all the stm32f103 based ones)
lethalbit[m] has joined #rust-embedded
<lethalbit[m]>
Speaking of trace, I wanna get one of those fancy lauterbach trace modules, many gigglebits of trace data
<FreeKill[m]>
We use a JTAG at 50MHz
<JamesMunns[m]>
lethalbit[m]: You got 50k just burning a hole in your pocket?
<lethalbit[m]>
Gosh I wish, lol
<JamesMunns[m]>
lethalbit[m]: Me too lol
<FreeKill[m]>
They said get one not buy one
<JamesMunns[m]>
I think the jtrace ones are cheaper (but still a couple k iirc)
<lethalbit[m]>
i'll just borrow my friends, she works at WD i'm sure they can spare one or two going missing /j
<FreeKill[m]>
Licensing SystemView is ~1.5K per JTAG you want to use it with
<lethalbit[m]>
sounds about right, ehehe
<JamesMunns[m]>
I mean it’s probably a reasonable fee if you’re doing something that needs it. If you spend a week less debugging something cursed
<JamesMunns[m]>
But yeah, not great for hobbyist/just in case use
<JamesMunns[m]>
Maybe we can get a Glasgow applet for it :D
<FreeKill[m]>
Oh well TBF hobbyists get it free
<FreeKill[m]>
It's 1.5k for people making profit
<FreeKill[m]>
Well... Revenue
<JamesMunns[m]>
Ah, can’t be too mad about it then
<lethalbit[m]>
I mean, one can always be mad about proprietary hardware and software vendor locking :v
<FreeKill[m]>
Nah its a number worth paying but something free would change the game.
<FreeKill[m]>
Plus the system view desktop software is kinda rubbish. I had to submit a big report pretty much as soon as i started using it cos the time keeping was broken 🙃
<FreeKill[m]>
s/big/bug/
<lethalbit[m]>
I really really need to get back to doing the RE on the PCIe analyzers I have, the agilent software is so awful
<JamesMunns[m]>
Yeah, free is good for the ecosystem, hard to get complicated niche tools built for free, esp with continued support (incl for for-profit users)
<JamesMunns[m]>
(The problem is capitalism, etc etc)
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
i509vcb[m] has quit [Quit: Idle timeout reached: 172800s]
KevinPFleming[m] has quit [Quit: Idle timeout reached: 172800s]
firefrommoonligh has quit [Quit: Idle timeout reached: 172800s]
Foxyloxy has quit [Read error: Connection reset by peer]
Foxyloxy has joined #rust-embedded
<dngrs[m]>
<dngrs[m]> "I need to leave now but I'll..." <- Alexander van Saase: so this is the device side of things: https://dpaste.org/WGpHv it's old, convoluted and uses RTIC 1 - but the general idea is this: you have an `enum Command {Log(Packet), .... other kinds of data ...}` and wrap defmt with this, on the host side you do the inverse and feed log packets to a defmt decoder, and do whatever you want with the non defmt stuff
<dngrs[m]>
the embedded web UI repo I posted earlier has a web frontend that does the ELF loading and defmt decoding. Sadly DefmtDecoder isn't the most ergonomic thing but, eh ..
<lethalbit[m]>
ahem Nya〜
ian_rees[m] has quit [Quit: Idle timeout reached: 172800s]
pcs38 has quit [Quit: leaving]
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]