<cr1901> Yuhan Lin: Your PR for pre_interrupt looks good, I want to look closely to understand how it works before merging, but I'm sure it's fine
<cr1901> I'll do that tomorrow, I'm multitasking rather badly tonight
<cr1901> and I want your PR to have my full attention
vancz has quit [Quit: vancz]
vancz has joined #rust-embedded
<cr1901> https://docs.rs/crate/msp430-rt/0.3.0/builds/499068 So uhhh, how does cortex-m fix this problem
<cr1901> https://docs.rs/crate/msp430-rt/0.2.4/builds/227228 Last successful build... I'm not sure what the significant difference is other than "--target isn't being explicitly passed anymore"
<cr1901> err, I mean "in 0.2.4, --target isn't passed. But in failing builds 0.2.5 and 0.3.0 --target is being passed". Hmmm...
vancz has quit [Quit: vancz]
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
vancz has joined #rust-embedded
ni has quit [Quit: WeeChat 3.0]
ni has joined #rust-embedded
<re_irc> <Mehmet Ali> For those interested, in 10 mins there is a Rust presentation on FOSDEM, and the conference is right here in Matrix chat.
<re_irc> <Mehmet Ali> https://matrix.to/#/#security:fosdem.org
crabbedhaloablut has quit [Ping timeout: 276 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc> <firefrommoonlight> Hey. After learning electronics/embedded etc about 2 years ago, I dove into Rust for MCU programming instead of the easy option of C or C++. Despite Rust still being immature in the field, I regret nothing
<re_irc> <firefrommoonlight> It doesn't limit things at all. Requires more work, eg building APIs you don't want to use Bindgen etc for, but not a big deal. The language design/docs/tooling etc is so much nicer
<re_irc> <firefrommoonlight> I feel like I can build whatever I want, and Rust will provide the benefits of a modern language, with no drawbacks comparable to its benefits
<re_irc> <firefrommoonlight> It doesn't limit things. Requires more work, eg building APIs you don't want to use Bindgen etc for, but not a big deal. The language design/docs/tooling etc is so much nicer
<re_irc> <firefrommoonlight> It doesn't limit things. Requires more work, eg building APIs you don't want to use Bindgen etc for, but not a big deal. The language design/docs/tooling etc is much nicer
<re_irc> <dalepsmith> seds: Maybe a crazy idea: have a "build.rs" that creates the asm include file? You can have rust macros in there, if that's what you need.
<seds> dalepsmith: might not be that crazy at all
<re_irc> <dalepsmith> Years ago, I was using a Moto supplied asm for 68K on dos. No macros at all. But I did have access to a dos m4! Was wonderful! Can do way more things than a C processor.
<re_irc> <dalepsmith> Like divert
<re_irc> <adamgreig> cr1901: https://github.com/rust-embedded/cortex-m/blob/master/Cargo.toml#L45-L54 I think is what you're looking for
<re_irc> <adamgreig> https://docs.rs/about/metadata
<cr1901> adamgreig: Tyvm
<cr1901> Can I pass -Zbuild-std=core as well?
<re_irc> <adamgreig> I don't think so
<re_irc> <adamgreig> you could try
<re_irc> <adamgreig> that second link has all options, including rustc-args
<re_irc> <adamgreig> oh hey actually
<re_irc> <adamgreig> their last example is # List of command line arguments for "cargo".
<re_irc> These cannot be a subcommand, they may only be options.
<re_irc> cargo-args = ["-Z", "build-std"]
<re_irc> <adamgreig> their last example is cargo-args = ["-Z", "build-std"]
<re_irc> <adamgreig> so, probably?
<cr1901> Oh, whoops. Totally missed the second link
<cr1901> Ty
starblue1 has quit [Ping timeout: 240 seconds]
starblue1 has joined #rust-embedded
sheb has joined #rust-embedded
<re_irc> <dirbaio> is there a way to register the same fn as a handler for multiple irqs?
<re_irc> #[interrupt] fn DMA_CHANNEL1 { on_irq() }
<re_irc> <dirbaio> this works but generates N dummy fns (the compiler won't merge them)
<re_irc> #[interrupt] fn DMA_CHANNEL2 { on_irq() }
<re_irc> #[interrupt] fn DMA_CHANNEL3 { on_irq() }
<re_irc> <dirbaio> oh wait it's merging them now lol??
<re_irc> 08004a34 g F .text00000004 DMA1_STREAM1
<re_irc> <dirbaio> 08004a34 g F .text00000004 DMA1_STREAM0
<re_irc> 08004a34 g F .text00000004 DMA1_STREAM2
<re_irc> ...
<re_irc> 08004a34 g F .text00000004 DMA1_STREAM3
<re_irc> 08004a34 <DMA1_STREAM0>:
<re_irc> 8004a34:f000 b800 b.w8004a38 <_ZN13embassy_stm323dma3dma6on_irq17hbcea388ab88510c7E>
<re_irc> <dirbaio> it still has an useless jump though
<re_irc> 08004a34 <DMA1_STREAM0>:
<re_irc> <dirbaio> it still has an useless jump though
<re_irc> 8004a34:f000 b800 b.w8004a38 <_ZN13embassy_stm323dma3dma6on_irq17hbcea388ab88510c7E>
<re_irc> 08004a34 <DMA1_STREAM0>:
<re_irc> <dirbaio> it still has an useless jump though
<re_irc> 8004a34:f000 b800 b.w8004a38 <_ZN13embassy_stm323dma3dma6on_irq17hbcea388ab88510c7E>
<re_irc> <dirbaio> this doesn't work, aww "#[export_name = "DMA1_STREAM0", "DMA1_STREAM1", ...]"
<re_irc> <adamgreig> Should be able to stick it in your memory.x for a specific executable
<re_irc> <adamgreig> Maybe harder in a library
<re_irc> <dirbaio> yeah it's for embassy-stm32 :S
<re_irc> <dirbaio> it's strange that it isn't inlining "on_irq"
<re_irc> <dirbaio> after deduplicating the fns, there's just one call to it so inlining it should be a no-brainer
<re_irc> <adamgreig> Does inline(always) do anything?
<re_irc> <dirbaio> yeah that seems to do the trick
<re_irc> <dirbaio> it's very risky though, if it decides to not dedup the fns for wahtever reason
<cr1901> Why is it very risky?
<re_irc> <dirbaio> instant bloat, 16 copies of the same fn! :D
<cr1901> Hmmm
<re_irc> <dirbaio> and indeed with opt-level=s it doesn't dedup them
<cr1901> Irony :(
<re_irc> <dirbaio> with opt-level=s and no inline(always) it doesn't dedup them either https://gist.github.com/Dirbaio/a79d60eb87b0c6e27ca900cd10e641ba
<re_irc> <dirbaio> stackoverflow is down 😱
<re_irc> <dirbaio> doesn't seem it's possible?
<re_irc> <dirbaio> it'd be possible to do if the vector table was built in the linker script instead of as a Rust struct
<re_irc> #[link_section = ".interrupts.DMA1_CHANNEL1"]
<re_irc> static IRQ: fn() = my_handler;
<re_irc> <dirbaio> rust code does
<re_irc> <dirbaio> and the linker script collects these statics from sections like ".interrupts.DMA1_CHANNEL1" in the right order etc
<re_irc> #[link_section = ".interrupts.DMA1_CHANNEL1"]
<re_irc> #[link_section = ".interrupts.DMA1_CHANNEL2"]
<re_irc> <dirbaio> rust code does
<re_irc> static IRQ: fn() = on_irq;
<re_irc> <dirbaio> it would be a mega breaking change to cortex-m-rt though lol
<re_irc> <adamgreig> seems a kind of niche use case too :/ with that setup you could very easily put two methods in one section and it would go badly wrong
<re_irc> <dirbaio> yeah the linker script would have to assert there's only one :D
<re_irc> <adamgreig> And the linker script would need to know the names of all the interrupts?
<re_irc> <dirbaio> and if there's zero, pad with one DefaultHandler
<re_irc> <dirbaio> adamgreig: PACs already generate a "device.x" today
<re_irc> <dirbaio> +with irq names
<re_irc> <adamgreig> Not sure you can even tell the linker to react by padding with default, hm
<re_irc> <dirbaio> yeah it seems very cursed
<re_irc> <dirbaio> very likely not worth it
<re_irc> <adamgreig> Can you just export some function pointers instead
<re_irc> <adamgreig> extern c static no_mangle dma2: fn() = dma1; ?
<re_irc> <dirbaio> as an irq handler? the vector will point to the pointer instead of to the pointed-to func
<re_irc> <adamgreig> Hmm