<re_irc>
<dirbaio> i guess the right way would be to add "__attribute__((alias))" support to rust.. :P
starblue1 has quit [Ping timeout: 256 seconds]
starblue1 has joined #rust-embedded
<re_irc>
<jorgeig> Hey folks, back in the grinder and I'm digging into defmt to reduce binary size and I'm a bit puzzled... I see that my binary contains a lot of core::fmt functions... I went to check in the "virgin" template app (https://github.com/knurling-rs/app-template) and even in that one I get a bunch of core::fmt functions... Am I missing something?
<re_irc>
Finished release [optimized + debuginfo] target(s) in 0.03s
<re_irc>
<jorgeig> I'm using the nrf52840-hal HAL, also tried with the stm32wlxx-hal one and same result
<re_irc>
<adamgreig> Probably due to a panic path somewhere, you could try with panic=abort
<re_irc>
<adamgreig> Maybe also set panic-immediate-abort and build-std to get rid of panics from inside std too
<re_irc>
<jorgeig> thanks Adam, I'll give it a try
emerent has quit [Ping timeout: 256 seconds]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
<re_irc>
<ia0> Did you try `DEFMT_LOG=off cargo bloat ...`? It will disable defmt otherwise you still get errors in release mode (as far as I recall)
<re_irc>
<ryan-summers> How big does formatting bloat end up being generally? On the order of a few KB?
<re_irc>
<ryan-summers> I've never had to fight it since the micros I use rust with generally have ~1MB flash
<re_irc>
<korken89> Normal fmt bloat is in our firmware 2x of the binary (26k without fmt bloat, and 79k with fmt bloat), now with defmt we are at 31k instead of 79k
<re_irc>
<ryan-summers> Hmm, so sounds like in the range of 50KB. Interesting, that's more than I'd expect
<re_irc>
<korken89> Only the float printing is like 25k
<re_irc>
<ryan-summers> But if you use serde-json or anything, won't you pay the cost of formatting as well, even if you have immediate panics?
<re_irc>
<korken89> You most likely will
<re_irc>
<korken89> Unless you use the slimmer version that uses ufmt
<re_irc>
<korken89> It does however not support floats
<re_irc>
<ryan-summers> Good to know - and yeah,. looking at cargo-bloat on some of my bins definitely indicates floats are in the range of 10-20kB at least
<re_irc>
<chmanie> I’m curious, has anyone found a way to use rust-analyzer with the "#[entry]" macro? For me it pretty much stops functioning for the file in which that macro is present.
<re_irc>
<gauteh> fn main() -> ! {
<re_irc>
<gauteh> fn main() -> ! {
<re_irc>
<gauteh> #[cfg_attr(not(test),
<re_irc>
fn main() -> ! {
<re_irc>
<gauteh> +entry)]
<re_irc>
<gauteh> Used to have "#[cfg_attr(not(test), no_std]" and also for no_main, but changed it to use a feature flag for "host-tests" because rust-analyzer would complain about missing Option and Return from core prelude
Guest2 has joined #rust-embedded
<re_irc>
<chmanie> gauteh that appears to be working, thank you!
<re_irc>
<gauteh> With this setup I can run tests on host with the help of a feature flag
starblue1 has quit [Ping timeout: 256 seconds]
starblue1 has joined #rust-embedded
<re_irc>
<MathiasKoch> What is the status of the Knurling sessions? Specifically the Neotrellis minesweeper 2021 version?
<re_irc>
<James Munns> If anyone is interested in helping with some not-so-embedded issues (writing a "clap" based CLI, writing integration tests using "insta" and "embedded-hal-mock"), the "pretty-hal-machine" crate has two help wanted issues that should be a good starting place!
<re_irc>
<James Munns> Happy to mentor or help you get familiar with things!
Socke has quit [Ping timeout: 250 seconds]
Socke has joined #rust-embedded
Guest2 has quit [Quit: Client closed]
<re_irc>
<thejpster> TIL you can't build M4 code with thumbv6m-none-eabi
<re_irc>
<thejpster> I mean, code to run on an M4.
<re_irc>
<thejpster> Because although the M4 is entirely ARM v6-M compatible, building cortex-m crate with thumbv6m turns off a bunch of stuff.
<re_irc>
<thejpster> Which is kind of annoying, because the instructions I choose to generate should be orthogonal to the CPU core features I have available.
<re_irc>
<dngrs (spookyvision@github)> tangentially - isn't there also some additional fun where you can't really tell from using a hardfloat target whether an FPU is actually available?
<re_irc>
<thejpster> correct! It's entirely permissible to use floating point instructions on a soft-float target
<re_irc>
<thejpster> The target only cares about whether you can pass floating point arguments in a floating point register
<re_irc>
<dngrs (spookyvision@github)> ah yes, the registers
<re_irc>
<dngrs (spookyvision@github)> which I assume are _not_ available on _every_ softfloat target? %)
<re_irc>
<thejpster> "fn do_maths(x: f64)" - x will go into a pair of integer registers on a soft-float target
<re_irc>
<thejpster> Floating point registers are a function of whether you have an FPU
<re_irc>
<dngrs (spookyvision@github)> ah, that way round
<re_irc>
<thejpster> So the hard-float target requires an FPU. But the soft-float target runs on FPU or non-FPU.
<re_irc>
<dirbaio> armv6m, armv7m are "architectures", which define both "available asm instructions" and "available features in core peripherals"
<re_irc>
<dirbaio> so cortex-m is correct here
<re_irc>
<thejpster> oooh, interesting
<re_irc>
<James Munns> Why would you want thumbv6m asm and the armv7m registers?
<re_irc>
<thejpster> because you have two applications in a workspace
<re_irc>
<thejpster> (which actually doesn't work for other reasons)
<re_irc>
<James Munns> Won't help for code portability, since you're still using registers that dont exist
<re_irc>
<thejpster> But also maybe you want the simpler set of machine instructions
<re_irc>
<adamgreig> it's true that you could use the thumbv6 instruction subset for a thumbv7 target
<re_irc>
<James Munns> Does that have any power/size benefit?
<re_irc>
<James Munns> I would think the compiler would handle that balance
<re_irc>
<thejpster> It's probably worse for both
<re_irc>
<adamgreig> generally only a downside, it needs more instructions to cover things v7 has built in
<re_irc>
<adamgreig> but it means you can have a single binary image that runs on multiple hardware
<re_irc>
<adamgreig> (and do like runtime detection of which peripherals to talk to)
<re_irc>
<thejpster> But I'm writing a ARM v6-M assembler/dissassembler and so I haven't done the ARM v7-M instructions.
<re_irc>
<James Munns> adamgreig: Ah yeah, that's the needed part I guess
<re_irc>
<thejpster> Also I have an ARM v6-M machine and an ARM v7-M machine that will run the same applications. But it's 'user-space' so who cares if cortex-m hides some NVIC stuff from me
<re_irc>
<James Munns> I guess that goes into the "if you're doing cursed stuff, just fork the lib and make it do what you want" territory
<re_irc>
<adamgreig> you could imagine having cortex-m use features to decide which platform it's building for, and they could be specific cortex-m CPUs, but detecting it from the target seems generally right for most people
<re_irc>
<adamgreig> like, if you know cpu=cortex-m7 you can enable things that you can't for cpu=cortex-m4 even though both are thumbv7em
<re_irc>
<thejpster> So this came about trying to compile stm32f4xx-hal for thumbv6m-none-eabi and getting some very weird errors about a funciton not existing
<re_irc>
<thejpster> And that function very much existing in docs.rs
<re_irc>
<thejpster> So maybe we should encourage HALs to blow-up earlier if you compile with the wrong ARM architecture
<re_irc>
<dirbaio> does m4 -> m7 enable new regs in core peripherals? 🤔
<re_irc>
<adamgreig> ideally docs.rs should be able to annotate which methods exist for which targets, but at the moment you have to select your target from the docs.rs dropdown
<re_irc>
<thejpster> No, M4 and M7 are both ARM v7E-M, AFAIK
<re_irc>
<thejpster> But this wouldn't be the first time I've been wrong in the last 10 minutes, so who knows
<re_irc>
<adamgreig> it does
<re_irc>
<adamgreig> cm7 defines some new peripherals not in cm4
<re_irc>
<James Munns> dirbaio: Some fp stuff maybe, like double precision stuff on some targets? But that's probably a code gen thing
<re_irc>
<thejpster> Oh no. WTF Arm.
<re_irc>
<adamgreig> both include all the ARMv7E-M peripherals of course
<re_irc>
<James Munns> Is that the m vs em part?
<re_irc>
<James Munns> Oh
<re_irc>
<adamgreig> no, that's DSP which is same for both M4 and M7
<re_irc>
<thejpster> E is the new bits not in an M3
<re_irc>
<adamgreig> well, E is the DSP set, which happens to not be in M3, yea
<re_irc>
<adamgreig> or it's the DSP+SIMD32 set depending on who in arm you ask about names...
<re_irc>
<adamgreig> the main new peripheral in CM7 is "AC", access control
<re_irc>
<adamgreig> in cortex-m we have a cm7 feature that enables it
<re_irc>
<James Munns> I can't remember what you have to do to enable double precision hard float like the H7 and imxrt has
<re_irc>
<adamgreig> it's documented in the cm7 user guide
<re_irc>
<thejpster> Well coming from the company who gave us ARM v8-M.main, I am not surprised.
<re_irc>
<adamgreig> for DP float you pass -C target-feature=+fp64
<re_irc>
<adamgreig> and maybe also +vfp5 if you want it
<re_irc>
<James Munns> Yeah, I needed that a bit ago for a customer project, but I'd forgotten in the intervening years
<re_irc>
<adamgreig> in ARMv8, the target no longer says whether DSP is included, it's awful
<re_irc>
<adamgreig> i.e. in v7 you had the E to mean DSP or not
<re_irc>
<adamgreig> in v8, DSP is still optional, it just doesn't change the architecture name any more
<re_irc>
<adamgreig> only main extension CPUs may implement the FPU or DSP extensions
<re_irc>
<adamgreig> but they don't have to... same with the security extension AKA "ARM® TrustZone® for ARMv8-M"
<re_irc>
<thejpster> So this is why I just want to use thumbv6m-none-eabi for everything
<re_irc>
<adamgreig> hehe
<re_irc>
<thejpster> OK, gotta run. Thank you all!!!!!!!!
<re_irc>
<James Munns> _sigh_
<re_irc>
<adamgreig> I wouldn't though, the codegen is much worse due to the much smaller instruction set
<re_irc>
<adamgreig> an appealing target for a disassembler though for sure
<re_irc>
<James Munns> Just disassemble some rp2040 code instead :D
<re_irc>
<dirbaio> ugh so the "access control" thing in M7 is not part of the thumbv7em arch? :D
<re_irc>
<adamgreig> correct
<re_irc>
<adamgreig> thumbv7em doesn't talk about AXI and cm4 doesn't use AXI, only AHB/APB, but the AC peripheral does a bunch of AXI related stuff
<re_irc>
<adamgreig> and also L1 cache, ECC, bla bla
<re_irc>
<dirbaio> fun shit
<re_irc>
<adamgreig> stuff that was added in cm7
<re_irc>
<adamgreig> yea :/
<re_irc>
<adamgreig> I would say it's quite rare to need to use AC
<re_irc>
<adamgreig> but in my experience every embedded project needs at least one feature that is only needed by like 1% of all projects
<re_irc>
<James Munns> I still wonder if it's worth learning all the cursed high end thumb7/8 stuff or if should just spend the time learning cursed cortex a stuff instead
<re_irc>
<adamgreig> so presumably someone needs to set the AHB priority or whatever
<re_irc>
<James Munns> Stick a bare metal A5 in everything
<re_irc>
<adamgreig> the cortex-a stuff is so much more cursed I think
<re_irc>
<adamgreig> you can get a lot more compute but you pay dearly with complexity and latency and interrupt jitter and stuff
<re_irc>
<James Munns> Yeah, probably :/
<re_irc>
<thejpster> (I'd love to stick to the F031 for my BMC but we couldn't buy any so switched to a Nucleo F401 for development...)
<re_irc>
<adamgreig> I haven't done anything not completely trivial on cortex-a though, so idk
<re_irc>
<James Munns> Gimme a stronk A5+a predictable m4f for realtime
<re_irc>
<James Munns> thejpster: Btw stm32g0s are in pretty deep supply at jlc
<re_irc>
<adamgreig> 👀
<re_irc>
<adamgreig> sadly still no h7
<re_irc>
<James Munns> 20/28/48/64 pin parts
<re_irc>
<adamgreig> they have a bunch of f1 too last i looked
<re_irc>
<dirbaio> and g0 is thumbv6m! :D
<re_irc>
<James Munns> adamgreig: They just charge you $20/ea
<re_irc>
<adamgreig> hah yea you have to really want them
<re_irc>
<thejpster> Got a whole page of notes on that - an LQFP-48 will replace the MC23S17 too, which is unobtanium
<re_irc>
<thejpster> But my colleage has an F401 Nucleo
<re_irc>
<adamgreig> the g0 is friendly though for sure
<re_irc>
<James Munns> That's what I use in sprocket and splitpea (qfn28 and tssop20 respectively)
<re_irc>
<adamgreig> i'm getting one of those cheap zync boards that comes second hand from bitcoin miners that got shut down in china soon, i guess i'll put rust on the cortex-a core :P
<re_irc>
<James Munns> adamgreig: Oh those are fun
<re_irc>
<adamgreig> sadly the zyncs that have 2x cortex-a and 2x cortex-r are quite a bit pricier, and also cortex-r seems even more annoynig
<re_irc>
<James Munns> Can you use amaranth on that fabric?
<re_irc>
<adamgreig> yea
<re_irc>
<adamgreig> amaranth can just emit verilog so it works on essentially every fpga
<re_irc>
<James Munns> adamgreig: Stick a riscv softcore on there lol
<re_irc>
<adamgreig> yosys can also do synthesis for the xilinx 7-series itself, though more limited, so I'll probably use vendor synthesis+pnr too
<re_irc>
<adamgreig> i wish they made zyncs with cortex-m7 hardcores instead
<re_irc>
<James Munns> Just fabric and hard MCU? Or with both hard cores?
<re_irc>
<adamgreig> yea, cortex-a hard core and riscv soft core, heh
<re_irc>
<adamgreig> well I guess fpga+cortex-a+cortex-m7 would be fun but even just fabric+cortex-m7 would be great
<re_irc>
<adamgreig> I guess I could just do a cortex-m soft core too, heh
<re_irc>
<adamgreig> bit annoying though
<re_irc>
<James Munns> adamgreig: I feel like... Someone makes that? Can't remember who tho
<re_irc>
<James Munns> adamgreig: The rare Cortex-M1!
<re_irc>
<James Munns> I still need to play around with "soft core plus custom periphs"
<re_irc>
<adamgreig> aliexpress is littered with them
<re_irc>
<dngrs (spookyvision@github)> ah good ole alix recycling
<re_irc>
<dngrs (spookyvision@github)> thx!
<re_irc>
<adamgreig> search EBAZ4205
<re_irc>
<dngrs (spookyvision@github)> thx!
<re_irc>
<James Munns> Lots of ecp5 boards from color light displays too, though no hard core
<re_irc>
<James Munns> But ecp5 has plenty of room for soft cores with lots extra
<re_irc>
<adamgreig> yea, for general fpga playing I'd recommend the ecp5 since the open source toolchain is mature and good, and also they're nice fpgas
<re_irc>
<dngrs (spookyvision@github)> I've got an ulx3s in the shame box
<re_irc>
<adamgreig> and if you already have a cmsis-dap probe for programming your microcontrollers, you can use it for ECP5 FPGAs too :P
<re_irc>
<James Munns> I have an ice40 and ecp5 waiting for me to finally decide to focus on that
<re_irc>
<adamgreig> James Munns: when that day comes, I have a super barebones example of amaranth + riscv softcore + rust on ecp5: https://github.com/adamgreig/rv-playground
<re_irc>
<James Munns> Once I get back to anachro PC, i want to use an FPGA as the northbridge controller
<re_irc>
<James Munns> 😍
<re_irc>
<James Munns> I knew you or disasm had one somewhere
<re_irc>
<adamgreig> should be very easy to adapt to ice40 too
<re_irc>
<adamgreig> implements one peripheral: a general purpose output register that's hooked up to one fpga output pin :P
<re_irc>
<adamgreig> can't argue with "cpu = minerva.core.Minerva()" :D
<re_irc>
<adamgreig> bam, a risc-v core
<re_irc>
<disasm> adamgreig: My favorite peripheral is the one that provides a status register with system clock frequency :)
<re_irc>
<housel> Is there a best practice for GPIO pin tristate mode in embedded-hal implementations?
<re_irc>
<gauteh> housel: I guess the stm32f... hals are the best reference. link in embedded-hal docs. i like atsamd-hal too, it uses const generics more (if i remember correctly)
<re_irc>
<housel> I looked at the stm32f4xx-hal and it doesn't seem to support putting outputs into tri-state mode
<re_irc>
<dngrs (spookyvision@github)> open drain in "PinState::High"?
<re_irc>
<housel> Ah, right
<re_irc>
<dngrs (spookyvision@github)> (disclaimer: I'm a total EE dummy, I might be totally off base)