04:16 <esden[cis]> hi, is there a better size reporting tool to cargo size? Something that shows how much rom vs ram the particular program uses? Mainly rom aka flash.

05:38 <M9names[m]> <Jonas[m]1> "I want the logging anyway, right..." <- there's also https://crates.io/crates/cargo-hf2, in case you're still having problems

06:02 <Charles[m]> (don't you have to solve the halting problem (among other things) to know the amount of ram a program will use?)

06:14 <esden[cis]> I am mainly interested in flash usage...

06:14 <esden[cis]> not dynamic ram usage

06:15 <esden[cis]> at most static and predictable without heap or stack

06:15 <esden[cis]> Charles ⚡️: but maybe you are just trying to be funny?

06:16 <Charles[m]> well you asked for a tool that can tell you how much ram a binary will use but i'm pretty sure that's impossible

06:16 <Charles[m]> and what's wrong with cargo size?

06:20 <esden[cis]> gcc has -Wl,--print-memory-usage which has much easier to read output... that is what I am seeking at least

06:20 <esden[cis]> size is just the same as gcc size which is pretty annoying to read

06:23 <esden[cis]> this is the output of `-Wl,--print-memory-usage`:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/PmMuNljYyPEsKeZQcReqvJQO>)

06:24 <esden[cis]> I hope that explains it Charles ⚡️ ...

06:27 <K900> Yeah that's just llvm-size being meh

06:27 <K900> You can try other --format options

06:27 <K900> I think it has a slightly less bad one

06:27 <esden[cis]> K900 ⚡️: does llvm linker not have a similar option to --print-size?

06:27 <esden[cis]> * to --print-memory-size?

06:28 <K900> It shouldn't even use the LLVM linker unless you tell it to

06:28 <esden[cis]> yeah I played with the format outputs, it is definitely "better" but still meh :)

06:28 <K900> Actually you can probably just `LDFLAGS="--print-memory-usage" cargo build`

06:28 <K900> But eh

06:28 <K900> It feels like something that should be done after

06:28 <esden[cis]> oooh! ok that is a good lead! Let me try that :)

06:29 <esden[cis]> nono, the linker knows how much space in the sections is, this is a "rightish" place to look ... who knows maybe it helps :D

06:34 <esden[cis]> ahh right... it is hiding a lot of the output ... now I know what you mean :/

06:35 <esden[cis]> It would indeed be better if it was a separate thing that can take the linker script with the sections defined and calculate the usage...

06:43 <esden[cis]> yeah I can force it to spit it out by adding:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/MvlEQDQTCdHSlNEVnKRZhiBu>)

06:47 <burrbull[m]> In .cargo.config there is [env] section

06:47 <burrbull[m]> * In .cargo/config.toml there is [env] section

06:56 <esden[cis]> burrbull: thanks I will look into it :)

07:08 <M9names[m]> ooh that looks nice esden, i might have to steal it :D

07:11 <M9names[m]> oh, not in lld yet? found a GSOC proposal for it though.

07:11 <M9names[m]> https://discourse.llvm.org/t/lld-linker-improvements-for-embedded/68129/13

09:44 <M9names[m]> output from espsegs is also very nice 👀

09:44 <M9names[m]> https://github.com/bjoernQ/espsegs

09:51 <FreeKill[m]> Hah this looks quite a lot like a tool I'm writing at work...

09:52 <FreeKill[m]> Maybe I should try and open source it

10:15 <FreeKill[m]> It gives you output like this:

10:15 <FreeKill[m]> as well as a table of all the symbols in that region ordered by size

10:16 <FreeKill[m]> If it's useful to other people i can try and hurry up making it available

10:31 <xiretza[cis]> zephyr also has a neat script that can show RAM and ROM usage by file path and symbol: https://github.com/zephyrproject-rtos/zephyr/blob/main/scripts/footprint/size_report

14:09 <JamesMunns[m]> <esden[cis]> "hi, is there a better size..." <- The main binutil is `nm`, `nm -nSC path/to/elf` shows you every ram and rom symbol known at link time

14:10 <JamesMunns[m]> `cargo bloat` is good for "vibes", it's less precise but gives a better overview

15:58 <almindor[m]> do we have anything for https://milkv.io/duo anywhere yet?

16:22 <therealprof[m]> <esden[cis]> "hi, is there a better size..." <- cargo bloat

16:27 <therealprof[m]> Doesn't show full RAM usage though. Only static variable RAM usage. There's also https://github.com/japaric/cargo-call-stack which can compute the actual RAM usage by the stack. Not sure how well that still works...

16:27 <FreeKill[m]> Puncover can also report stack usage

16:28 <mabez[m]> therealprof[m]: dirbaio's fork is less fragile because it uses llvm-sys for parsing, instead of a hand rolled one: https://github.com/Dirbaio/cargo-call-stack

16:29 <mabez[m]> I also like that it doesn't try and build the project, you pass it a path to the elf

16:29 <mabez[m]> Works quite well for me

17:03 <adinack[m]> i've noticed there seems to not really be any abstraction of flash for the stm32f0xx-hal, do i just have to write to registers manually? 😭

17:28 <FreeKill[m]> <mabez[m]> "I also like that it doesn't..." <- My tool uses the elf and map file output 😁 so hopefully will work as well

18:29 <GrantM11235[m]> <adinack[m]> "i've noticed there seems to..." <- It looks like embassy-stm32 supports flash on the f0 https://docs.embassy.dev/embassy-stm32/git/stm32f030c8/flash/index.html

20:40 <esden[cis]> <FreeKill[m]> "image.png" <- Wow that looks great! 🤩

20:41 <esden[cis]> <xiretza[cis]> "zephyr also has a neat script..." <- ahh right, should add it to the list and try it out

20:41 <esden[cis]> <JamesMunns[m]> "`cargo bloat` is good for "vibes..." <- ahh yes, just tried it out, it is definitely useful to get a "feel"

20:42 <esden[cis]> <therealprof[m]> "Doesn't show full RAM usage..." <- That sounds useful when I have to figure out ram usage. My main current issue is flash usage that I am trying to get a grip of.

20:44 <FreeKill[m]> Try puncover

20:44 <FreeKill[m]> Interface is fantastic, though not terse

20:44 <FreeKill[m]> Very good for understanding the size of your linked symbols, and how they get linked in

20:45 <esden[cis]> yes will check that out too. Saw the recommendation above. I think I used it already for another project to find places to optimize.

20:45 <FreeKill[m]> And does static stack usage analysis!

20:45 <esden[cis]> It is not bad.

20:45 <FreeKill[m]> FreeKill[m]: Though you need to make sure your compiler spits out .su files

20:47 <esden[cis]> I am looking forward to seeing more of these analysis tools to be integrated into the rust ecosystem better. Or similar tools to sprout within the ecosystem. But of course this will work in the mean time.

20:47 <esden[cis]> Especially for embedded being able to profile flash and ram usage is quite important.

20:47 <esden[cis]> That said, thank you all for the suggestions. All very useful. :)

20:48 <FreeKill[m]> Unfortunately it's extremely hard to do generically. But we could definitely do better

20:48 <FreeKill[m]> The IAR C compiler - for all its faults - has some amazing utility here

20:48 <esden[cis]> There is always space for improvement. :)

20:49 <FreeKill[m]> You can mark functions as roots for stack usage analysis. You can declare what dynamic dispatch routes should be considered. You can instruct it to ignore recursion

20:49 <esden[cis]> Even the horrendous M16 compiler I used ages ago had some fantastic memory location and usage visualization. It provided it quite out of the box.

20:50 <FreeKill[m]> And you can annotate your functions "do not pass the link stage if this function has >X worst case stack usage"

20:50 <FreeKill[m]> I hate that embedded compilers are so technically phenomenal and then terrible in every other way

20:51 <esden[cis]> Yeah it is a lot of specialized work unfortunately. One can only hope it will get better. But there is a good trajectory. :)

20:55 <therealprof[m]> I find cargo bloat insanely useful for profiling applications. Usually people are not just interested in learning whether the application will fit the flash but also which parts of the application are contributing the most to the size. I'm using it to track and compare the code generation abilities of the rust compiler...

20:56 <esden[cis]> Ohh yeah I agree. The output is very informative. I am playing with it right now.

21:16 <adinack[m]> <GrantM11235[m]> "It looks like embassy-stm32..." <- thanks, i'm trying to *not* use embassy for this board but maybe i can learn how to add flash to the stm32f0xx-hal from this

21:17 <therealprof[m]> adinack: stm32f0xx-hal could use some more maintainers 😉

21:18 <adinack[m]> i know! i've had 3 PRs in line for weeks! 🤣

21:19 <therealprof[m]> I just remembered... Looking at them now. 😉

21:19 <adinack[m]> oh haha i didn't mean that, take your time :)

21:24 <therealprof[m]> It's all good. I think I even told you to nudge me after you made the changes... I get like 400 (mostly drive-by) mail messages every week from GH; SNR is really bad there.

21:24 <adinack[m]> oh god

21:32 <therealprof[m]> Yeah. So feel free to tag me here or via PM whenever you need me.

21:41 <adinack[m]> ok therealprof my PR has too much "sausage making" as you call it and I'm not good enough at git to fix it and now the CI is failing on code that I didn't even touch so I'm gonna close this one and open a new one where aaalllll the changes are in just one commit :)

21:44 <therealprof[m]> adinack[m]: Don't need to close this. Create a new branch with the changes and force push it over that one.

21:46 <adinack[m]> ok i'll try that thanks lol

21:47 <therealprof[m]> adinack[m]: Preserves the history and discussion. 😉

21:55 <yruama_lairba[m]> hi, i'm trying to design a "safe" abstraction for a dma buffer that can be read or written while a dma is running, but it's seems very tricky and i'm not sure about property or constrain to uphold safety. Does anyone tryiong to design such thing ?

21:55 <yruama_lairba[m]> s/tryiong/tryed/

22:17 <yruama_lairba[m]> at first, i think i need a Sync + Send type with shared mutability. I think this can be assumed ok if each element of my buffer can be atomically read from or written to the buffer, and i think this can be guaranteed by the hardware ( dma and MCU)

22:18 <yruama_lairba[m]> * and MCU), Am i correct ?

22:36 <yruama_lairba[m]> second point, the buffer need to have a static lifetime to be safe. Because of memory forget, you can bypass safety mechanism that could disable dma stream when dropping a object.

22:44 <yruama_lairba[m]> and the next point get me trouble, i think i need to use "read_volatile" and "write_volatile" but i read it's unsound when reference to that data exist because compiler can generate spurious read. I think i need to use a custom pointer, but i don't know how to have safe abstraction to build this pointer

23:38 <Tommy_plug[m]> Hello everyone I'm a professional Grower and psychedelics supplier, I supply products such as;... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/IFdQKjmWCsTmgvCOSkLMRqSK>)

23:46 <GrantM11235[m]> yruama_lairba: Use `&[AtomicU8]` (or u16/u32) instead of volatile

23:47 <GrantM11235[m]> Is it possible for the moderator bot to also delete the spam?

23:53 <adinack[m]> therealprof: sorry i had to leave but i'm back and i think i cleaned up the PR properly, but is CI broken? the error is in `spi.rs` which i didn't touch?

23:57 <adamgreig[m]> lol, the bot wasn't quite quick enough there huh