<blaine[m]>
I've noticed that my build size is growing quite a lot – I did a little refactoring and moved some code that was in main.rs into a couple of module files, and it's almost doubled the size of my build. Is that expected? I've tried several things listed in various documents and so far haven't been able to shrink it back down.
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
release builds? are you using link time optimisation? got lots of potential panics/expects - log strings in your modules?
<blaine[m]>
Yup – interestingly, release builds didn't shrink things much. The build size jumped from 1 MB to 2 MB when I moved the code around, so I assume it's not log strings (and I didn't add many, if any)?
<blaine[m]>
definitely plenty of panics/expects – that could be it, though again I didn't add a ton. Is there a rule of thumb for how much each one adds?
<blaine[m]>
I've also seen pretty big jumps in both directions. I wasn't paying close attention at first, but things seem to have stabilised for now. I actually removed a bunch of dependencies with some of the changes that caused the biggest size jump, which is adding to my confusion.
<vollbrecht[m]>
one nice feature of panics is that they can have full path + line number etc in them. That can eat a lot of space. If you now split 1 file into many files you now get a bunch more path possiblilitys
<vollbrecht[m]>
you can test some of the impact by for example compiling with -Zlocation-detail=none
<vollbrecht[m]>
this will completly remove that location output from panic messages.
<vollbrecht[m]>
just make two bins and compare them with and without it
<blaine[m]>
makes sense. I went from 1 file to 4, all in the root, so presumably not a huge change, but I hadn't tried that flag – I'll give it a go and see what happens, thanks!
<vollbrecht[m]>
also panic-immediate-abort can drastically decrease file-size. In the end it boils down to debugability vs size ;D
<GrantM11235[m]>
Make sure to measure the size with cargo size from cargo-binutils, don't just look at the size of the of the file
<GrantM11235[m]>
s//`/, s//`/, s/of the//
<vollbrecht[m]>
since i know you are using an esp @blaine you can also do `espflash save-image --chip <your-esp> <your-elf-file>
<vollbrecht[m]>
<name-of-output-binary>` that will crate a raw .bin file that you can inspect with a hexeditor ;)
<vollbrecht[m]>
that way you get often a good understanding what crazy strings etc end up beeing inside your final image
<vollbrecht[m]>
but in the end i would only start using all this, when you a) finished your app b) really need some space because your flash capacity is reached, or are forced because you are using multiple OTA partitions that are smaller.
<vollbrecht[m]>
But till your app is not fully developed its just nicer to have good debug output. Only after everything is working i would go and try to get a nice small build
<blaine[m]>
For sure; mostly just trying to keep an eye on things in case there are practices that I should be doing as I'm learning to avoid bloat, but it sounds like most of it is debug related anyhow, so that's reassuring.
<vollbrecht[m]>
its bloat for sure, but it should not impact execution performance. So yeah in the end you can try to get rid of the stuff.
<JamesMunns[m]>
"has primitives that allow for implementation of llvm CAS builtins"
<JamesMunns[m]>
Riscv also has AMO instructions as well as LL/SC instructions, for example
badyjoke[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has joined #rust-embedded
<dav1d>
If I have log statements in my code but don't ever read them will this cause issues for my devices or are non-consumed log messages just lost?
<JamesMunns[m]>
Probably depends on what log system you're talking about
<JamesMunns[m]>
the cortex-m semihosting and itm crates will block forever if you send logs and nobody consumes them
<JamesMunns[m]>
the rtt logging crates (including defmt-rtt) will generally drop logs (overwrite oldest) if no debugger is attached, tho attaching probe-rs run or probe-run (I think?) will switch defmt-rtt logging into "block on full" mode
<dav1d>
esp32s3 with esp-println
<JamesMunns[m]>
not sure! But the answer is usually "it depends", hopefully their library documents it!
<danielb[m]>
even then the answer depends on the interface :)
<danielb[m]>
serial-jtag will block for a short while at first, but throw away bytes after that timeout
<danielb[m]>
* while at the first, * first flush, but
<dav1d>
thanks, my main takeaway from this is, I better disable all log messages by default :D
M9names[m] has joined #rust-embedded
<M9names[m]>
that seems like a strange takeaway? i would have thought: verify if it behaves how i want, and if it doesn't make it so it does
<M9names[m]>
it's incredibly useful to be able to extract information from a running firmware without affecting timing. having that on by default provides a lot of value.
<thejpster[m]>
unless you look at it from Microsoft's point of view, then it's genius
<thejpster[m]>
thunking between Arm 64 and x86-64 code without having to move stuff between registers and the stack, because they agree on where everything lives and how big it s
<thejpster[m]>
(I squashed it all, because upstream don't need to see my working out)
<whitequark[cis]>
which is kind of the point of xtensa, isn't it
TomB[m] has joined #rust-embedded
<TomB[m]>
<whitequark[cis]> "which is kind of the point of..." <- True, I wonder if riscv will end up the same way... so many adhoc ISA extensions
<thejpster[m]>
<whitequark[cis]> "which is kind of the point of..." <- clue's in the name, I guess
bomb has joined #rust-embedded
<thejpster[m]>
nothing like opening an PR to really make those spelling mistakes pop out at. you
<thejpster[m]>
s/.//
bomb_ has joined #rust-embedded
bomb has quit [Killed (NickServ (Forcing logout bomb -> bomb))]
bomb_ is now known as bomb
gordio[m] has quit [Quit: Idle timeout reached: 172800s]
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
Mark[m] has joined #rust-embedded
<Mark[m]>
Hey everyone, I have a somewhat noobish and theoretical question about embedded graphics. There is the SSD1963 display controller, which has a rather large frame buffer. I’ve been wondering, could embedded graphics be used with an external frame buffer in its current form? Obviously a driver would need to be created for the display controller, but other than that, would it work efficiently? I’m thinking of performance bottlenecks
<Mark[m]>
like reading the buffer state from the display, etc
<ryan-summers[m]>
<Mark[m]> "Hey everyone, I have a somewhat..." <- The short answer is always that it depends. For example, you could have your frame buffer in an external flash, but that's connected to the AXI bus of your controller so the latency of accessing it is super lower.
<ryan-summers[m]>
If you have it i.e. in something like an I2C EEPROM, it's going to be insanely slow
<ryan-summers[m]>
s/lower/low/
<ryan-summers[m]>
But in general, when designing a GUI application, I'd almost always opt to go for having a RAM-based frame buffer (or no buffer) instead of offloading it elsewhere. You're just introducing a lot of difficulty in your system imho
AtleoS has quit [Ping timeout: 260 seconds]
<whitequark[cis]>
any data in the framebuffer but not actively used for display purposes is also known as "free swap space"
<whitequark[cis]>
for example if the display has character generator ram but you aren't using the character mode? you could put your stack there, with enough effort
IlPalazzo-ojiisa has quit [Quit: Leaving.]
AdamHott[m] has joined #rust-embedded
<AdamHott[m]>
Hi all, regarding the update to the tooling section, thoughts on this?
<cr1901>
This ExtInt type does not implement the embedded-hal traits for Input. So, what you're telling me, is that if I'm using GPIO interrupts I can't use the embedded HAL traits on SAM D?
<danielb[m]>
what about the impl InputPin on the page you linked?
<danielb[m]>
apologies I was looking 2 versions into the future
<cr1901>
There isn't one
<cr1901>
Yea, I'm stuck with 14.0 b/c that's what my board (Trinket m0) supports