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
<cr1901> jannic: The next few weeks (till December 5) are gonna be weird for me. I can't promise I'm gonna be able to finish the proof of concept until then
<cr1901> (Assuming they're on the Matrix side)
dc740 has quit [Remote host closed the connection]
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<re_irc> < (@jannic:matrix.org)> cr1901: Don't worry, for me it's just a hobby. There shouldn't be any pressure.
<re_irc> <brendansbits> Hello, how can I check how much memory my embedded code is using on an STM32 target. There are references on various pages to 'cargo size', but when I run that command I get an error saying that there is no subcommand named 'size'.
<re_irc> '''
<re_irc> (Background: I am getting an error:
<re_irc> ERROR panicked at 'memory allocation of 640 bytes failed', library/alloc/src/alloc.rs:405:9
<re_irc> ''' when I am running some code on an STM32 target
<re_irc> <brendansbits> Hello, how can I check how much memory my embedded code is using on an STM32 target. There are references on various pages to 'cargo size', but when I run that command I get an error saying that there is no subcommand named 'size'.
<re_irc> (Background: I am getting an error...
<re_irc> '''
<re_irc> ERROR panicked at 'memory allocation of 640 bytes failed', library/alloc/src/alloc.rs:405:9
<re_irc> <brendansbits> Hello, how can I check how much memory my embedded code is using on an STM32 target. There are references on various pages to 'cargo size', but when I run that command I get an error saying that there is no subcommand named 'size'.
<re_irc> (Background: I am getting an error...
<re_irc> ERROR panicked at 'memory allocation of 640 bytes failed', library/alloc/src/alloc.rs:405:9
<re_irc> ...when I am running some code on an STM32 target when I am trying to push a value into a vector.)
<re_irc> < (@9names:matrix.org)> to use cargo size you need to install cargo binutils
<re_irc> cargo install cargo-binutils
<re_irc> rustup component add llvm-tools-preview
<re_irc> <rjmp> That sounds like you are running out of heap though, and cargo size cant tell you that
<re_irc> <brendansbits> rjmp: Ah, yes I am. How can I check how much heap I am using?
<re_irc> <rjmp> Are you doing a lot of allocations? Are you using the cortex-m allocator? Did you initialize it with storage? There is the size method on the allocator, which can give some indication: https://docs.rs/alloc-cortex-m/latest/alloc_cortex_m/struct.CortexMHeap.html#method.used
<re_irc> <rjmp> Remember, its possible to have more than 640 bytes available but not contiguous. This is one big reason that many apps avoid heap usage, or minimize it at least
<re_irc> <rjmp> Often if you need storage buffers, fixed size buffer pools are a better option, but i dont really know your situation
<re_irc> <brendansbits> Cheers. I am using cortex-m-alloc (I want to use vectors in my code)
<re_irc> static ALLOCATOR: CortexMHeap = CortexMHeap::empty();
<re_irc> {
<re_irc> #[global_allocator]
<re_irc> <brendansbits> I will try and call the 'used' method in the rtic tasks to see how much of the heap is being used.
<re_irc> <rjmp> How much memory do you expect to allocate? If you are allocating and freeing alot you could run into fragmentation problems.
<re_irc> <rjmp> Another thing is that the vec may be pre allowing more than you actually need. If you know in advance how big your vec is going to get, it helps to pre allocate it
<re_irc> <rjmp> * allocating
<re_irc> <brendansbits> rjmp: Do you mean:
<re_irc> let buffer_voltage = Vec::<u16>::with_capacity(10);
<re_irc> <rjmp> Yep
<re_irc> <brendansbits> I don't quite understand these results:
<re_irc> defmt::println!("{}", ALLOCATOR.used()); \\ gives a value of "0"
<re_irc> let buffer_voltage = Vec::<u16>::with_capacity(20);
<re_irc> let buffer_current_1 = Vec::<u16>::with_capacity(20);
<re_irc> < (@k900:0upti.me)> I'm guessing they get dropped
<re_irc> < (@k900:0upti.me)> If you're not using them later
<re_irc> < (@k900:0upti.me)> That's an optimization LLVM is allowed to make
<re_irc> <brendansbits> : Of course! I have them commented out in the code because I am having trouble getting one vector to work...
<re_irc> <brendansbits> In an RTIC task, I am having trouble getting the used heap size (I haven't worked out how/if I can share the ALLOCATOR as a local resource because I need to assign a lifetime to the borrowed reference)
<re_irc> let heap_usage = CortexMHeap::used(&CortexMHeap {});
<re_irc> --> src/bin/main.rs:286:45
<re_irc> error: cannot construct `CortexMHeap` with struct literal syntax due to private fields
sknebel has quit [Read error: Software caused connection abort]
sknebel has joined #rust-embedded
<re_irc> < (@datdenkikniet:matrix.org)> do you set up the allocator with the "#[global_allocator]" attribute?
<re_irc> < (@datdenkikniet:matrix.org)> assuming so, you should just be able to access "used" through the static that you put under it
<re_irc> < (@datdenkikniet:matrix.org)> i.e.
<re_irc> static GLOBAL: CortexMHeap = CortexMHeap::new(); // With correct constructor and stuff
<re_irc> // Somewhere in your task
<re_irc> let used_bytes = GLOBAL.used();
<re_irc> #[global_allocator]
<re_irc> < (@datdenkikniet:matrix.org)> * stuff, and possibly another name
faern has quit [Read error: Software caused connection abort]
faern has joined #rust-embedded
<re_irc> <brendansbits> Ah, that worked when I moved the #[global_allocator] outside the init loop. Thankyou.
<re_irc> <brendansbits> Thankyou rjmp and . My problem wasn't caused by the allocator at all - I had forgotten to remove items off the vector causing it to grow larger than the heap.
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc> < (@frozendroid:matrix.org)> brendansbits: If you don't necessarily need dynamic allocation, I can recommend using https://docs.rs/heapless instead.
<re_irc> < (@frozendroid:matrix.org)> Gives you data structures like Vec's without needing an allocator, due to them being fixed-size
causal has joined #rust-embedded
dc740 has joined #rust-embedded
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
<re_irc> <Georges P> Hi, I am looking for a way to add my SVD file to the PAC crate, so when it is in another bin crate dependency it finish somewhere in the target/ directory and can be used by the debugger to know about MCU peripherals.
<re_irc> < (@jessebraham:matrix.org)> Not sure if there's a better way, but can you just add something like this to the build script?
<re_irc> let out = &PathBuf::from(env::var_os("OUT_DIR").unwrap());
<re_irc> File::create(out.join("my-device.svd"))
<re_irc> .unwrap()
<re_irc> < (@jessebraham:matrix.org)> And then just "include = []" in your "Cargo.toml" fo the SVd I guess?
<re_irc> <Georges P> Thx I will try that
<re_irc> <brendansbits> : I didn't know about heapless - thankyou.
<cr1901> 9names: Is there an example for the HAL for calling a __time_critical_func function from C?
<re_irc> < (@9names:matrix.org)> I don't think so. I assume you're asking for calling a function at an exact interval, where the timing is generated by a hardware interrupt?
<cr1901> I have a PIO wrapper function in C, and I want to call it from Rust
<re_irc> < (@9names:matrix.org)> I hadn't encountered __time_critical_func, looks like it's just an alias for __not_in_flash_func which uses a linker region pragma to put the function in ram.
<re_irc> So you should just call the function name as per normal.
<cr1901> ahhh okay
<re_irc> < (@9names:matrix.org)> I assume rust won't attempt to inline C code...
<re_irc> < (@dirbaio:matrix.org)> apparently it's possible to do cross-language LTO if you've compiled the C code with clang instead of gcc
<re_irc> < (@dirbaio:matrix.org)> but I tried ~2 years ago and failed to make it work
<cr1901> Doesn't matter, the C code is compiled by gcc
<re_irc> < (@dirbaio:matrix.org)> thankfully I have no C code anymore :D
IlPalazzo-ojiisa has quit [Remote host closed the connection]