02:41 <mkj[m]> some interesting embedded rust here. https://news.ycombinator.com/item?id=44971998 "For now we've hardcoded Bosch, Bafang, Brose and a few others (more coming), and we plan to open-source the communication protocol soon so that anyone can upload their own WASM code on the battery to talk to any [bike battery] controller!"

02:42 <mkj[m]> * some interesting embedded rust here. https://news.ycombinator.com/item?id=44971998 "For now we've hardcoded Bosch, Bafang, Brose and a few others (more coming), and we plan to open-source the communication protocol soon so that anyone can upload their own WASM code on the battery to talk to any \[bike motor\] controller!"

07:30 <thejpster[m]> I have an AM243x Launchpad and I got Rust going on the R5. The problem is the R5 can only let the debugger read memory when stopped, so RTT doesn’t work.

08:00 <danielb[m]> Stop-mode rtt is still a pretty okay thing if you dont have anything else

08:02 <diondokter[m]> danielb[m]: Isn't semihosting better then? That at least gives a signal to the debugger when there's data

08:03 <danielb[m]> Semihosting is net terrible

08:04 <danielb[m]> Current formatted semihosting needs to trigger a breakpoint for every single fragment, try dumping an array like that 😅

08:11 <diondokter[m]> Oh yeah, that's awful.

08:11 <diondokter[m]> Adding a buffer (à lá RTT) in between probably works better

08:11 <diondokter[m]> s/lá/la/

08:12 <danielb[m]> * formatted semihosting print needs to

08:12 <danielb[m]> Also the debugger needs to notice the breakpoint

08:13 <diondokter[m]> Is that slower than reading memory?

08:13 <danielb[m]> No, it just depends on when the drbugger decides to poll

08:14 <diondokter[m]> Right

08:16 <M9names[m]> I expect it's less time for halt-read-run than brkpt-wait-read-run, the only benefit for breakpoint is the firmware chooses the halt position

08:17 <M9names[m]> Can you use SWO thejpster ?

08:17 <danielb[m]> Yeah rtt can be very intrusive, we had several issues caused by randomly halting firmware

08:17 <danielb[m]> Which is also a very good test method lol

12:29 <thejpster[m]> <M9names[m]> Can you use SWO thejpster ?

12:29 <thejpster[m]> I don’t think so. Pretty sure it was JTAG.

12:29 <thejpster[m]> I think you can do RTT on the M4 core and IPC it from the R5 to the M4. I just haven’t had the time to try.

12:30 <thejpster[m]> That would also mean loading code to RAM using the M4, which would need to take the R5 out of reset.

14:30 <corecode[m]> is there any way to allocate and initialize a struct on the heap?

14:30 <corecode[m]> i'm getting a stack overflow because of my huge application state struct

14:31 <diondokter[m]> corecode[m]: Yes, but you're not gonna like it

14:31 <JamesMunns[m]> You can allocate a MaybeUninit, and unsafely initialize it in place

14:31 <corecode[m]> pah

14:31 <diondokter[m]> Yup, that

14:31 <MartinSivk[m]> I think I saw a macro for that

14:31 <JamesMunns[m]> https://docs.rs/pin-init/latest/pin_init/ might be able to help, I haven't looked into it too deeply

14:31 <JamesMunns[m]> "In place construction" is the term you're looking for, generally.

14:34 <corecode[m]> so weird that the language doesn't support that yet

14:36 <corecode[m]> is there a way to figure out what the deepest stack size is?

14:37 <JamesMunns[m]> Somewhat: https://github.com/Dirbaio/cargo-call-stack

14:39 <TomB[m]> alternatively... write the stack region with a pattern, periodically walk the stack region for where the pattern has been over written using asm at your initialization vector

14:40 <TomB[m]> * alternatively... write the stack region with a pattern, periodically walk the stack region for where the pattern has been over written. Using asm at your initialization vector to do this prior to using rust/c type stuff.

14:40 <corecode[m]> oh man this is terrible, i need close to O(N^2) stack size, because every ::new allocates everything on the stack

14:40 <MartinSivk[m]> I prefer the flip stack approach, it hard faults on overflow :)

14:41 <corecode[m]> or at least 2N

14:41 <JamesMunns[m]> TomB[m]: I think the cortex-m crate has a stack painting feature? I'm not sure if probe-rs supports automatically checking it

14:41 <corecode[m]> yea i just enabled stack limits and now i'm here

14:41 <TomB[m]> JamesMunns[m]: nice to know!

14:41 <MartinSivk[m]> corecode: Been there too.. in place init language support would have been nice

14:41 <corecode[m]> yea this is a problem. i don't want to pay 2N stack size

14:42 <JamesMunns[m]> MartinSivk[m]: It is being worked on, atm, but not like, "this week/month"

14:42 <TomB[m]> mpu regioning the stack is another option for some devices (zephyr uses this) though I think newer armv8m supports some sort of stack limit and exception

14:42 <MartinSivk[m]> My use case was a framebuffer structure for ESP32S3 SPI attached RAM.. encapsulated unsafe and pinning helped

14:42 <corecode[m]> yes, i have that

14:43 <corecode[m]> very convenient to find it

14:43 <corecode[m]> this is my main app state

14:43 <JamesMunns[m]> I expect it to get quite a bit better over the next year or so, rust-for-linux and c/c++ interop folks are all pushing for improvements on in-place construction

14:44 <MartinSivk[m]> Yeah, we are using the latest and greatest so it is expected stuff gets rough :D

14:44 <JamesMunns[m]> (that doesn't help today, but Soon™️ hopefully!)

14:44 <TomB[m]> this is for like static initializers and .data type stuff? or is this to avoid the "move" that kind of happens for fn new(some_params: P) -> Self

14:44 <TomB[m]> * this is for like static initializers and .data type stuff? or is this to avoid the "move" (copy) that kind of happens for fn new(some\_params: P) -> Self

14:44 <TomB[m]> * this is for like static initializers and .data type stuff? or is this to avoid the "move" (copy) that kind of happens for fn new(some\_params: P) -> Self?

14:44 <corecode[m]> new returning self

14:45 <corecode[m]> in several levels

14:45 <corecode[m]> machine dependent owns machine independent state

14:45 <corecode[m]> seems every new needs all of the members on the stack in order to then copy it into the parent stack frame?

14:46 <TomB[m]> yikes

14:48 <corecode[m]> yes yikes

14:48 <TomB[m]> well when it doubt make it a global... can't waste/use excessive memory accidently if its already pre-allocated and maybe even pre-initialized in the elf in .bss/.data

14:48 <TomB[m]> s/it/in/

14:48 <corecode[m]> i don't have const new

14:50 <TomB[m]> unsafe all the things with global mutable statics

14:50 <TomB[m]> back to the stone ages

14:55 <TomB[m]> wonder if misra-rust ever came about it'd have a rule akin to the stack allocated dynamically sized array rules for C...

14:55 <JamesMunns[m]> that's for `alloca`, right? Rust just doesn't have that, and it's somewhat hard to even sort of do that safely

14:57 <TomB[m]> alloca or vla

14:57 <corecode[m]> meh and gdb ptype/o doesn't work. says my type is dynamic

15:00 <corecode[m]> is there some tool that will show my type size (and paddings?)

15:01 <corecode[m]> i'm surprised that my app state is over 700 bytes

15:02 <JamesMunns[m]> `core::mem::size_of::<T>()`?

15:06 <corecode[m]> yea i mean a more recursive way of figuring out the components

15:06 <corecode[m]> like what gdb's ptype/o should do

15:07 <thalesfragoso[m]> corecode[m]: r-a shows sizes on rover.

15:07 <thalesfragoso[m]> * r-a shows sizes on hover.

15:07 <thalesfragoso[m]> I mean, when you hover on the type definition.

15:09 <thalesfragoso[m]> <JamesMunns[m]> that's for `alloca`, right? Rust just doesn't have that, and it's somewhat hard to even sort of do that safely

15:09 <thalesfragoso[m]> It does (did?) have something on unstable, namely unsize_locals. But I remember they wanted to split that into unsized function parameters and alloca like stuff.

15:10 <thalesfragoso[m]> Since the unsized parameters were the most important.

15:12 <corecode[m]> thanks for the hint with hover

15:12 <corecode[m]> unfortunately it shows the mock sizes -_-

15:15 <thalesfragoso[m]> mock?

15:18 <mkj[m]> RUSTFLAGS="-Zprint-type-sizes" cargo +nightly build will print all the sizes of everything

15:21 <corecode[m]> thanks

15:21 <corecode[m]> thalesfragoso: yes, i use mocks for testing

15:26 <thalesfragoso[m]> <thalesfragoso[m]> Since the unsized parameters were the most important.

15:26 <thalesfragoso[m]> It's even used in libstd to implement FnOnce for Box<dyn FnOnce>.

15:26 <thalesfragoso[m]> * It's even used in libstd to implement FnOnce for Box<dyn FnOnce> .

15:27 <thalesfragoso[m]> What, element doesn't let me write `Box<dyn FnOnce>`...

17:29 <thejpster[m]> behold - my worst idea ever... (full message at <https://catircservices.org/_irc/v1/media/download/ASkHR2-hmR8brCxxBbNprzI3yERVqAiu92uPR6dWmCUEyShPPhXKqaQrtErMDgS_hkIeco2uXYnCoDdg4yDMDCK_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9ZWkxkQ2RpYURZcGFuU05zcVdYeUt6b1k>)

17:29 <thejpster[m]> a file that is both a shell script and a batch file, and hence can be used as the cargo runner on both Linux, macOS and Windows

17:33 <vollbrecht[m]> did you set a filename extension or use a blank name?

17:37 <JamesMunns[m]> <thejpster[m]> behold - my worst idea ever...

17:37 <JamesMunns[m]> for those following along at home, these are called "polyglot files": https://en.wikipedia.org/wiki/Polyglot_(computing)

17:41 <thejpster[m]> <vollbrecht[m]> did you set a filename extension or use a blank name?...

17:41 <thejpster[m]> I think it has to be called .bat or .cmd on Windows, so I called it .cmd.

17:41 <thejpster[m]> Linux and macOS seem to execute it in the default shell, despite a lack of shebang, which surprised me

17:42 <thejpster[m]> really wish cargo let me set a runner according to the host target, not just the cross-compile target

17:43 <thejpster[m]> the other option was making a rust program called qemu-defmt which you could install, and it would spawn qemu and grab the output and defmt decode it. The reason I can't just put a long command line in as the runner is that I need to pass the filename to both qemu and defmt-print, and the runner string doesn't do variable expansion - it only tacks the filename on as the last argument.

17:44 <thejpster[m]> qemu_run.sh is https://github.com/ferrous-systems/threadx-experiments/blob/windows-fixes/qemu-cortex-r5-app/qemu_run.sh

17:44 <thejpster[m]> also, this example now not only runs Rust on ThreadX on Arm Cortex-R5, but also adds defmt over semihosting.

18:08 <whitequark[cis]> <thejpster[m]> Linux and macOS seem to execute it in the default shell, despite a lack of shebang, which surprised me

18:08 <whitequark[cis]> this is a shell feature, not OS feature

18:48 <wassasin[m]> Monthly whine that workspaces with mixed targets are terrible

18:58 <vollbrecht[m]> we need something like a clippy lint for cargo setups to tell people to dont do that :D

19:25 <jason-kairos[m]> <wassasin[m]> Monthly whine that workspaces with mixed targets are terrible

19:25 <jason-kairos[m]> Maybe if a mob of 50 or so embedded developers got together, they might be able to organize an effort to do something. Event if that something might be to complain to the cargo maintainers.

19:25 <jason-kairos[m]> I really wish it was better thought out.

19:25 <jason-kairos[m]> * something might merely be to, * to complain very politely to the

19:37 <thejpster[m]> <whitequark[cis]> this is a shell feature, not OS feature

19:37 <thejpster[m]> even when executed from inside cargo by virtue of being given in `runner = "..."`?

19:42 <thejpster[m]> looking at the cargo source code, I think it just does Command::new()

20:44 <whitequark[cis]> <thejpster[m]> even when executed from inside cargo by virtue of being given in `runner = "..."`?

20:44 <whitequark[cis]> ohhh interesting, not sure then