ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
<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 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.
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
Louq has joined #rust-embedded
Louq28 has joined #rust-embedded
Louq28 has quit [Ping timeout: 250 seconds]
Louq has quit [Ping timeout: 250 seconds]
<thejpster[m]> TIL: thinking about targets as “has CAS Atomic” and “don’t have CAS atomic” is not technically correct -
<thejpster[m]> 32 bit Arm has load-exclusive/store-exclusive, which is not CAS but does let you implement fetch_add.
<thejpster[m]> perhaps needs a wording change
<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.
bomb has joined #rust-embedded
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
bomb has quit [Quit: 💣]
<thejpster[m]> teeeeeeechnically armv5te-unknown-linux-gnu does have fetch_add, but it cheats and uses the kernel to implement it.
<thejpster[m]> but this is quite specifically the arm bare-metal doc
<thejpster[m]> and teeeeeechnically ARMv7-M is older than ARMv6-M, but honestly who cares because Arm's naming is just generally baffling
<dirbaio[m]> wat
<thejpster[m]> ARMv6-M is ARMv7-M with bits cut off to make it more like an ARMv6 core. But it definitely came later. Cortex-M3 is the OG Cortex-M.
<dirbaio[m]> interesting, TIL!
<thejpster[m]> it's really very very simple
<thejpster[m]> as this attached diagram will show
diondokter[m] has joined #rust-embedded
<diondokter[m]> lol
<thejpster[m]> now, what do you call a target for the Arm Cortex-R82 (an Armv8-R CPU that only operates in Aarch64 mode on A64 instructions)
<JamesMunns[m]> thejpster[m]: Automotive pfaff
<thejpster[m]> armv8raarch64-unknown-none-eabi? aarch64v8r-unknown-none-eabi? armv8r-none-elf?
<thejpster[m]> (aarch64 targets are none-elf, and arm/thumb targets are unknown-none-eabi, for reasons no-one knows)
<dirbaio[m]> target naming is such a disaster
<JamesMunns[m]> com.arm.8.r.64-none-eabi
<thejpster[m]> I tried to stop them making arm64e-apple-darwin but I think I failed
<thejpster[m]> and then arm64ec-pc-windows-gnu arrived
<thejpster[m]> (arm64e is apple's name for Aarch64 with Pointer Authentication, arm64ec is x86-64 but using Arm A64 instructions)
<thejpster[m]> ah, tagentially: soon you can buy a Cortex-M55 with an Ethos-U55 NPU
<dirbaio[m]> arm64ec is sooooo cursed
<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]> s/s/is/
<dirbaio[m]> yeah it's amazing
<thejpster[m]> last call on before I try and send it upstream
spinfast[m] has joined #rust-embedded
<spinfast[m]> Arm targets are still saner than xtensa, bar none
<spinfast[m]> Every xtensa target is custom
AtleoS has joined #rust-embedded
pbsds has quit [Ping timeout: 252 seconds]
pbsds3 has joined #rust-embedded
<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> Anyone familiar with how to do GPIO interrupts on the SAM D family?
dreamcat4 has joined #rust-embedded
<cr1901> AFAICT, you use the EIC peripheral (External Interrupt Controller). This in turn returns a ExtInt* type:
<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
<dirbaio[m]> why would newer HAL versions drop support for boards?
<cr1901> >over 2 years ago
<cr1901> I guess it's more "nobody's upgraded it yet"
<dirbaio[m]> ah
<dirbaio[m]> outdated BSPs
<cr1901> I would create a newtype, but I don't have access to the inner type (possibly not even via unsafe/transmute)
<dirbaio[m]> i'd suggest using atsamd-hal directly and skipping the bsp
<dirbaio[m]> copypaste whatever you need from the bsp into your project
<cr1901> Shame, but looks like that's what I have to do
<cr1901> Or I could fork it and contribute an up-to-date version
<danielb[m]> if you have the energy and the motivation, sure!
<dirbaio[m]> can someone reproduce this? all i'm getting is an ICE from Miri
<dirbaio[m]> aha I can repro if I simplify the code a bit... (full message at <>)
<dirbaio[m]> seems to require critical-section locking and threads or something
<dirbaio[m]> nope the error is back 😵‍💫
<dirbaio[m]> and I can't get this to repro without embassy at all :|
<cr1901> ouch :o
bomb has quit [Quit: 💣]
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded