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
IlPalazzo-ojiisa has quit [Quit: Leaving.]
ChristianHeussy[ has joined #rust-embedded
<ChristianHeussy[> Hi all, what's the best way to handle vendor linker scripts and startup code in the context of cortex-m-rt? I'm working with an Infineon device that supplies a [linker script and startup code](https://github.com/Infineon/TARGET_KIT_T2G-B-H_LITE/tree/master/COMPONENT_CM0P/TOOLCHAIN_GCC_ARM). Primarily, I need to invoke `SystemInit()` from the vendor startup code to setup clocks etc but this function depends on symbols in the
<ChristianHeussy[> vendor linker script.
Amanieu has quit [Ping timeout: 255 seconds]
Guest7282 has left #rust-embedded [Error from remote client]
<adamgreig[m]> it depends how you're integrating - if you want to use the vendor linker script and startup code, you might be better off letting the C side handle all the setup and just call functions from your rust code?
<adamgreig[m]> you can provide your own linker script easily enough (just replace -Tlink.x in the .cargo/config.toml with -Twhatever.ld), but cortex-m-rt requires various symbols in the linker script for its startup code (which means: copying .data into RAM, zeroing .bss, turning on the FPU, etc)
<adamgreig[m]> usually "setup clocks etc" isn't startup code so much as system initialisation after startup is complete, but it's the sort of thing you could probably just write in rust if you want rust to handle setup
<adamgreig[m]> or put another way: cortex-m-rt replaces using the vendor's linker script and startup assembly, the files you linked to, so you can just not use them. if you need extra symbols to exist in the linker script, you can add them in memory.x, or by copying cortex-m-rt's link.x and modifying it yourself
Amanieu has joined #rust-embedded
<M9names[m]> Probably worth mentioning that infineon have their own guide for t2g devices. If it doesn't explain things well enough it might be worth creating an issue?
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
SanchayanMaity has quit []
SanchayanMaity has joined #rust-embedded
<ChristianHeussy[> So it sounds like I have two options:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/RpNpYXJKUqtpbbXxCtCpbfSH>)
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
juliand[m] has joined #rust-embedded
<juliand[m]> Looks like Infineon's idea of Rust support didn't get too far yet, did it?
<juliand[m]> Will there be more in the future?
<ChristianHeussy[> Frankly no, and they [declared victory](https://community.infineon.com/t5/Blogs/Infineon-leads-the-way-Enabling-Rust-for-MCUs-in-the-semiconductor-industry/ba-p/410425) a little too early imo. It seems like they want to provide more support and I hope it improves.
<ChristianHeussy[> * Frankly no, and they [declared victory](https://community.infineon.com/t5/Blogs/Infineon-leads-the-way-Enabling-Rust-for-MCUs-in-the-semiconductor-industry/ba-p/410425) a little too early imo. It seems like they want to provide more support and I hope it improves.
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
lockna[m] has joined #rust-embedded
<lockna[m]> Hey guys!
<lockna[m]> I would like to write an assembler, what would be an appropriate architecture for it, which isn't that hard in things like instruction encoding etc.
K900 has joined #rust-embedded
<K900> If you're just doing it for fun, CHIP-8 maybe?
<lockna[m]> definitely is for fun and learning, was looking at a "real" architecture
<lockna[m]> MIPS maybe?
<K900> rv32i?
jake_001[m] has joined #rust-embedded
<jake_001[m]> Does anyone know of a good example repo for TDD with embedded rust?
<jake_001[m]> I'm trying to get away from using my hacked together shell scripts.
<JamesMunns[m]> rv32i would be pretty interesting and non complex. I'd probably suggest picking whatever has the best qemu or other simulation environment for poking around :)
<jake_001[m]> also +1 for rv32imac the ISA isn't a total pita to read.
<JamesMunns[m]> jake_001[m]: > <@jake_162:matrix.org> Does anyone know of a good example repo for TDD with embedded rust?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ZeMiewPEMSIKNxjDBMIEpJcB>)
<JamesMunns[m]> if you can split out your "hardware specific" and "business logic", using a pretty normal `cargo watch -x test` workflow tends to work really well in my experience
<JamesMunns[m]> * "hardware specific code" and
<JamesMunns[m]> If you also need to run tests on-target tho, it gets a little more involved :)
<lockna[m]> K900: thanks! will have a look at it
<JamesMunns[m]> btw, does anyone know offhand if there's an rv32i target for QEMU that has peripherals or things like an interrupt controller?
<jake_001[m]> James Munns: the wch chips
<jake_001[m]> the ch32v203 or the ch32v307 both have a ton of peripherals
<JamesMunns[m]> sorry, looking specifically for a QEMU target
<JamesMunns[m]> e.g. one that has simulated peripherals
<JamesMunns[m]> for example in cortex-m, the lm3s6965evb target has some peripherals like a UART I think? that are simulated, so it's not just the core.
<jake_001[m]> ah, I think you would pretty much just have the star-five stuff then.
<jake_001[m]> also thanks for the cargo watch suggestion, it looks a lot cleaner than me tossing regex at the wall
<JamesMunns[m]> Yeah, I saw that, but it looks more "application profile", but maybe it's reasonable to write bare metal for it too
Guest7282 has joined #rust-embedded
<PeterHansen[m]> Phew... after a *very* long evening, I have it shrunk to something manageable, if not quite minimal.
<PeterHansen[m]> Some notes are in the README...
<JamesMunns[m]> hell yeah I'm gunna go grab an nrf52840 board
<PeterHansen[m]> dirbaio: Although I'm not convinced yet that this is in any way an embassy problem per se, I have not yet been able to reproduce the problem without spawning two tasks, even though those tasks just sleep (and have code following the sleep that is technically related to the potential Option::None debug format issue that appears to be involved, even though that code does not get executed).
<PeterHansen[m]> James Munns: I'd be willing to bet this would occur on any nrf52.
<PeterHansen[m]> The memory.x is generic enough aside from flash size (I should have made that like 32K maybe), and the Cargo.toml mentioning 52840.
<PeterHansen[m]> Note my comment about managing to turn the hard fault into a completely different symptom at one stage: a panic from critical-section appearing to fail, inside rtt-target. Almost certainly a red herring in that i don't think the critical-section can actually fail, but it's almost certain the underlying bug is causing memory corruption. It definitely fits with how the problem can come and go with silly things like removing
<PeterHansen[m]> code that is never executed anyway.
<PeterHansen[m]> It's also quite interesting to me that the implementation of the Option Debug derive appears to have changed in 2023-08-09 and later, as did that memcpy. Given that this so far does seem quite tied to the Option Debug derive (and specifically formatting a None variant), maybe that's a hint of something.
<PeterHansen[m]> I'm completely beat after a long day on other stuff, then a long evening (it's 3am here) shrinking this down from a non-trivial code base, but if I see tomorrow morning that anyone reproduced this it will make my whole week...
<PeterHansen[m]> Another stray thought while I remember: I had shrunk RAM quite a bit, and was thinking it could possibly be shrunk even more, to the minimum, and then do a dump of RAM in the good vs bad cases and compare, to see whether there's any obvious sign of corruption.
<JamesMunns[m]> building and running, I'll let you know if I can repro it
crabbedhaloablut has joined #rust-embedded
<JamesMunns[m]> got it, only happens in debug mode, not release mode
<JamesMunns[m]> it doesn't seem to be affected by codegen units 1 (vs 8) or incremental false (vs true)
<JamesMunns[m]> using lto=thin or lto=false both make the issue go away (it only presents with lto=full)
<JamesMunns[m]> s/full/'fat'/
<JamesMunns[m]> yep, it's definitely waking into memory wtf
<JamesMunns[m]> haha whew yeah that's interesting
Guest7282 has left #rust-embedded [Error from remote client]
<JamesMunns[m]> that's actually the first call, where it's RIGHT, the next time we end up there r3 has been clobbered by the memcpy
t-moe[m] has joined #rust-embedded
<t-moe[m]> (at the risk that some of you have already seen my message in the probe-rs or esp-rs chatroom, here it is anyway:)... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/fawYNNyVKYxedUVeKQiMGmvO>)
Guest7282 has joined #rust-embedded
<M9names[m]> it only has a single uart and gpio peripherals emulated, so maybe not very exciting from a dev point of view but i don't know of any qemu mcu target that is fully fleshed out either
<M9names[m]> <JamesMunns[m]> "Yeah, I saw that, but it looks..." <- there's also a sifive_e qemu target, which is rv{32,64}imac and definitely not "application profile".
<M9names[m]> the official docs don't seem to really describe the target very much, this announcement from sifive seems the most useful:
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
djdisodo[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]> So, I've hit the end of the time that I can spend on this, I could use help from anyone that can help debug. *something* is going wrong, and I think it is with LLVM LTO'ing virtual functions. CC Peter Hansen:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/SOLuWOaHpOrjWodyqkVXTYiw>)
<JamesMunns[m]> Essentially, we return to the same place twice, which doesn't look right. I dunno if that `push {r7,lr}` + `pop {r7,pc}` combo is "normal", or really where we're supposed to return at all
<dirbaio[m]> oh boi
<JamesMunns[m]> The issue ONLY seems to come up (at least with this repro) with LTO and non release builds, potentially because the dynamic dispatch gets confused, and maybe it all gets inlined away (and avoids LTO problems) if optimized
<JamesMunns[m]> ghidra things this function is SUPPOSED to look like this:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/oOLouZOKpMZTgKXYzgEnSbKU>)
<dirbaio[m]> these outlined functions are cursed though, they don't conform to any ABI
<JamesMunns[m]> where uVar1 is r3 here
<dirbaio[m]> it's just LLVM sees a chunk of repeated ASM and rips it out
<dirbaio[m]> I wouldn't be surprised if it confuses ghidra
<JamesMunns[m]> yeah, the issue isn't the OUTLINED_FUNCTION, it's this part:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/AlSlqUORdeFgikbQRlVGjfRZ>)
<JamesMunns[m]> that function actually basically returns to where it was called
<JamesMunns[m]> also there is no actual return AFTER that call, it's just a straight up bx r3 followed by garbage
<dirbaio[m]> that's a tail call into a function pointer
<dirbaio[m]> it'd normally be blx r3; bx lr, but it gets optimized to bx r3
<JamesMunns[m]> yeah, but we didn't restore LR after calling OUTLINED_FUNCTION_14(), so it still points to THIS function, instead of the parent function
<JamesMunns[m]> so instead of returning from `<...>::fmt` like a tail call, it just returns TO `<...>::fmt`, and then calls `(*UNRECOVERED_JUMPTABLE)(uVar1,"None ");` again, but this time `uVar1` has been clobbered by memcpy, so we jump to where the memcpy was copying to lol
<dirbaio[m]> true... seems kind of a bug in outlining
<dirbaio[m]> outlining a chunk of code clobbers LR, because it's needed to return back
<dirbaio[m]> seems like it's outlining that function without "realizing" the original LR is still needed
<JamesMunns[m]> yeah, that makes sense, that gives me something I feel like I can report, I was missing the tail call part
<JamesMunns[m]> lemme open a PR
<JamesMunns[m]> err, issue
<dirbaio[m]> the tail call is maybe the cause? like it'd normally be blx r3; bx lr so it'd "see" there's a LR use there, but if it optimizes to bx r3 it "seems" like it's no longer needed but still is
<dirbaio[m]> definitely very sus
<dirbaio[m]> wow
IlPalazzo-ojiisa has joined #rust-embedded
<JamesMunns[m]> I also realized Peter Hansen is the one that reported the "whoops we broke the stack ABI" issue, so he might get credit for "finder of the most cursed bugs"
<dirbaio[m]> wow yeah 🤣
<dirbaio[m]> and that was already his 2nd cursed bug right? there was another one before
<JamesMunns[m]> oh really? oh no lol
<dirbaio[m]> seems like an llvm bug
<dirbaio[m]> next step would be "bisect llvm" 💀
<dirbaio[m]> * llvm bug, if it started happening on the llvm 17 upgrade
<JamesMunns[m]> yeah, the fact that it happened on LLVM upgrade and ONLY happens with lto is sus, IMO
<JamesMunns[m]> Ah, interesting, 1.74 was branched prior to the LLVM17 update, so would also explain why nobody has seen it in stable
<JamesMunns[m]> btw Noah, `panic-rtt-target` is missing a release, the latest version still depends on v0.3.x instead of v0.4.0, and `v0.4.0` of rtt-target was never tagged on git.
<Noah[m]1> <JamesMunns[m]> "btw Noah, `panic-rtt-target..." <- oh shoot, I can fix that :)
<Noah[m]1> man I wanna just do OSS for a while -.-
Lumpio[m] has quit [Quit: Idle timeout reached: 172800s]
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
<ChristianHeussy[> * Frankly no, and they [declared victory](https://community.infineon.com/t5/Blogs/Infineon-leads-the-way-Enabling-Rust-for-MCUs-in-the-semiconductor-industry/ba-p/410425) a little too early imo. It seems like they want to provide more support and I hope it improves.
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
<PeterHansen[m]> <dirbaio[m]> "and that was already his 2nd..." <- Yep, I had also noticed that nrf-softdevice critical-section impl bug. Glad even if I don't contribute much code that I can at least help contribute to robustness. :-)
<dirbaio[m]> oh yeah! that one was nasty too
<JamesMunns[m]> Also, huge props for catching that Peter Hansen, it's always a pleasure to work on your cursed repros :D
<PeterHansen[m]> I'm just so glad you guys are here run the last mile (or the second half of the marathon, as the case may be).
<PeterHansen[m]> I assume I caught that first because everyone else seems to run from embedded alloc like the plague...
<dirbaio[m]> doesn't seem related to alloc to me
<JamesMunns[m]> btw, more or less how I chased it down, if you want to do so in the future:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/QURZZYcqlimZEPECIeXhdQDn>)
<JamesMunns[m]> If you do layout split after attaching with GDB, you get a three-panel setup with code, ASM, and a console
<JamesMunns[m]> that's what I used while `si`, which is "step instruction", which was basically single-stepping the assembly
<JamesMunns[m]> it also prints to the console every time you jump into a different function, which is how I kept a record of "where was I before it all went wrong"
<JamesMunns[m]> then whenever it ran off the end, and I wasn't ready, I used:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/zbNVxCCXnUfTrNRoCRLOfluL>)
<JamesMunns[m]> oh, and monitor reset to reset the device, after clearing and resetting the breakpoints
<JamesMunns[m]> Not sure if that's helpful, but was my process at least, and I'm sure someone will tell me there's a better way :D
<PeterHansen[m]> James Munns: Should I merge in your PR on my repo, or is there no point now that you forked and added a link to yours in the issue? Whatever will help anyone looking into this....
<JamesMunns[m]> I mostly opened it for completeness, and to help at least solve the "oops locked twice" mystery
<JamesMunns[m]> feel free to merge or not, it also has a lot of commented out shenanigans :D
dsmith-work has joined #rust-embedded
<JamesMunns[m]> <PeterHansen[m]> "I assume I caught that first..." <- I think it might be a combo of:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/XZvadiEiWQwomJsvlOjWsLVP>)
<Ecco> Damn
<Ecco> I'm getting an empty binary when I build for thumbv8m.main-none-eabihf
<Ecco> like I get an ELF file
<Ecco> but… it's just empty
<dirbaio[m]> missing -Tlink.x
<dirbaio[m]> * missing -Tlink.x link argument
<dirbaio[m]> you need to have it, either in build.rs or in .cargo/config.toml
<Ecco> oh, ok!
<Ecco> thanks
<Ecco> It's weird that this doesn't yield any error
<Ecco> I might try and find a fix for this
<Ecco> I'm not familiar enough with Rust just yet tho
<dirbaio[m]> I don't think it's fixable, it's just that the linker does the wrong thing by default
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
<Ecco> ok :)
<Ecco> (good, it's working now. Thanks!)
kpcyrd[m] has joined #rust-embedded
<kpcyrd[m]> Hello! I'm trying to setup a hello world for the digispark attiny85, I got flashing to work with the arduino ui and [this blink code](https://github.com/Rahix/avr-hal/tree/main/examples/trinket), but I when trying to setup my project I get `LLVM ERROR: Expected a constant shift amount!` (I haven't yet figured out why the setups differ, both are using `nightly-2023-08-08`)
<kpcyrd[m]> The command I'm running is cargo build --release - ah never mind though, the build profiles are configured in the workspace's Cargo.toml that I also had to copy
AdamHott[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<PeterHansen[m]> <JamesMunns[m]> "I think it might be a combo of:..." <- > <@jamesmunns:beeper.com> I think it might be a combo of:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/HOZIlfhKEIwXwFWPbNLwYUxj>)
<JamesMunns[m]> ah, nevermind me: it's not release but it IS opt-level='z'
<PeterHansen[m]> In fact... my dev and release profiles are identical for my own modules other than dev has debug-assertions and release does not...
<adamgreig[m]> hi @room , meeting time again! agenda is https://hackmd.io/FmYNq5OLS_SkEhIqG2qJrw, please add anything you'd like to announce or discuss, we'll start in a few mins
<dirbaio[m]> I think z is what enables the outliner
<JamesMunns[m]> which, the only difference is that release defaults to opt-level=3
<adamgreig[m]> (weird, it does seem to have stopped pilling the at-room bit for me, element bug maybe?)
<PeterHansen[m]> James Munns: Yes, "z" or I believe "s"... but I guess those are the same other than loop vectorization?
<JamesMunns[m]> dirbaio[m]: is it not active in 3? 👀
<dirbaio[m]> no (outlining makes code slower in exchange for making it smaller)
<PeterHansen[m]> So only those of us prioritizing minimal flash usage over speed will notice this... ?
<therealprof[m]> adamgreig[m]: Not sure, cinny is weird as well.
<therealprof[m]> dirbaio[m]: There's an outliner?
<JamesMunns[m]> Little announcements from me:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/OEtaYOTdBihNsvvgbJvkfByq>)
<therealprof[m]> I think only the inlining parameters change.
<dirbaio[m]> the outliner finds identical chunks of ASM, moves them to a _OUTLINED_FUNCTION_nnn and replaces them with a bl to that
<PeterHansen[m]> Just realized the only reason I never hit this with my release profile is probably because it only triggers when I'm formatting Options for RTT logging, which would not happen with "debug-assertions" false... but I'd be leery of running any code with nightly after 08-08 if it meant there could be mysterious other failures that aren't as blatant as a hard fault.
<adamgreig[m]> ok, let's begin!
<adamgreig[m]> just a couple of announcements, ip_in_core (move std::net::IpAddress and friends into core) entered FCP so we might see it soon https://github.com/rust-lang/rust/issues/108443#issuecomment-1852361189
<adamgreig[m]> and esp-hal 0.14 is out, thanks jessebraham! https://github.com/esp-rs/esp-hal/releases/tag/v0.14.0
<adamgreig[m]> JamesMunns[m]: > <@jamesmunns:beeper.com> Little announcements from me:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/hyndFDYDnRQZwzESSjcBXqol>)
<adamgreig[m]> JamesMunns[m]: hah, what are the odds? 2 weeks ago!
d3zd3z[m] has joined #rust-embedded
<d3zd3z[m]> One minor announcement, I've started an RFC: https://github.com/zephyrproject-rtos/zephyr/issues/65837
<adamgreig[m]> nice!
<therealprof[m]> <JamesMunns[m]> "Since LLVM12: https://www.linaro..." <- Oh well, in LLVM on ASM level... But I also think that Rust will inline less with -z...
<d3zd3z[m]> I am finding some interesting comments of people, for example, not realizing that we can have a bunch of structs in Rust that doesn't actually take any space.
<adamgreig[m]> it will be interesting to hear how that goes, for sure
<adamgreig[m]> it would be neat if you can implement embedded_hal support from zephyr so that all the various drivers on crates.io could be used by zephyr applications, possibly even C applications :p
<adamgreig[m]> ok, on with the agenda, I don't have anything to discuss for embedded-hal (for once...) beyond noting there's 16 days until the planned 1.0 release
<adamgreig[m]> any HAL team people have anything about it we should mention?
<dirbaio[m]> funny enough there's a MCP to add Zephyr support to Rust https://github.com/rust-lang/compiler-team/issues/629
<dirbaio[m]> what will be first, Rust support in Zephyr, or Zephyr support in Rust? 🤣
<dirbaio[m]> nothing HAL-related from me
<dirbaio[m]> we should finish the migration guide
<dirbaio[m]> and update readmes etc
<d3zd3z[m]> One of the issues I'm concerned about is that Zephyr doesn't currently build with clang/llvm. In the past I have had issues with compiler-support symbols clashing between gcc and llvm.
<JamesMunns[m]> dirbaio[m]: And schedule a crate of beer to be sent to dirbaio for running the release over the holidays :)
<d3zd3z[m]> Presumably, the various drivers in Zephyr wouldn't be too difficult to do with hal. Or impossible, depending on the HAL.
<dirbaio[m]> lol
<d3zd3z[m]> For example, embedded storage would be difficult, because the flash parameters are trait constants, whereas they are queried from the driver in Zephyr.
romancardenas[m] has joined #rust-embedded
<romancardenas[m]> From the RISC-V side we already crated the [`riscv-pac`](https://github.com/rust-embedded/riscv/tree/master/riscv-pac) for interrupt related traits
<romancardenas[m]> And I opened a PR for RISC-V standard peripherals that uses `riscv-pac` and is `e-h-1` ready :D https://github.com/rust-embedded/riscv/pull/164
<adamgreig[m]> someone's opened https://github.com/rust-embedded/cortex-m/issues/499 on cortex-m about VectActive::from() not subtracting 16, which we fixed in the unreleased master branch at the same time as changing the type from u8 to u16
<dirbaio[m]> oh hey, the riscv-pac crate is the "pac interface crate" idea
<adamgreig[m]> the type change made it a breaking change, but I wonder if we should backport just the -16 fix to c-m 0.7
<adamgreig[m]> hopefully once we split cortex-m up a bit more it won't need to be "only one instance may appear in build tree and also every PAC uses it", at which point it's much easier to release 0.8
<adamgreig[m]> but for now, the -16 probably should be backported, and isn't a breaking change as such (though might cause some confusion if anyone's using the bad behaviour...)
<romancardenas[m]> Should the pac interface crates use the links cargo feature to ensure there is only one version when compiling?
<JamesMunns[m]> (sorry, jumping in, but if anyone knows how to pull in a new LLVM commit and rebuild a version of rustc from it, I [could use a hand](https://github.com/rust-lang/rust/issues/118867#issuecomment-1852667831)!, the outlining issue may have already been fixed upstream)
<adamgreig[m]> romancardenas[m]: hm, good question, I don't think it's necessary? e.g. if there was an update to it, a new version of the riscv crate would use the new traits, and so the pac would have to implement the new ones for it to compile, but the pac could _also_ implement the old traits at the same time, and then still work with older versions of the riscv crate
<PeterHansen[m]> James Munns: Note my comment in the issue re `lto = "thin"` can also produce this bug.
<JamesMunns[m]> PeterHansen[m]: Updated title!
thejpster[m] has joined #rust-embedded
<thejpster[m]> adamgreig: is that the "semver trick"?
<thejpster[m]> and can the LLVM thing wait until we're finished?
<adamgreig[m]> it's not semver trick, no
<adamgreig[m]> that's when you release a new version of the old major release that depends on the new major release and re-exports compatible traits from it
<adamgreig[m]> we/I want to never do that again
<adamgreig[m]> it's a huge pita and usually breaks something or other, plus by definition you can't re-export everything from the future because some of them have changed
<adamgreig[m]> this is just normal "you can depend on two versions of a crate at once" (so long as neither sets the links key, anyway!)
<PeterHansen[m]> (Didn't realize there's a meeting active... my apologies.)
<thejpster[m]> gotcha
<adamgreig[m]> same as how a lot of HALs support e-h 0.2 and 1.0 at the same time (although usually with features for now since 1.0 isn't released)
<adamgreig[m]> no worries on the meeting front, there's not much to discuss this week anyway
<adamgreig[m]> in fact I think that's all the things worth discussing, open to any other topics
<adamgreig[m]> anything else anyone wants to discuss this week?
<thejpster[m]> do we have a good sense of what people should do if they have additional rw regions?
TomB[m] has joined #rust-embedded
<TomB[m]> <adamgreig[m]> "it would be neat if you can..." <- e-h 1.0 is very unlikely to be fully usable given the DelayUs stuff, none of the Zephyr APIs for buses include delays injected into transactions like that, if Delay is ignored then its almost a direct match up
<adamgreig[m]> the DelayNs trait, or the Delay operation in SPI?
<TomB[m]> I saw the PR for imxrt-hal that add e-h 1.0 and Delay is confusing there as well, what exactly is expected to provide that delay? a scheduler? a timer queue? an async runtime? a busy wait?
<TomB[m]> adamgreig[m]: the delays within a spi operation
<TomB[m]> e.g. write, delay, read, delay, delay, write
<adamgreig[m]> it's up to the SpiDevice implementation what's used, it could be any of the above
edm has quit [Ping timeout: 260 seconds]
<adamgreig[m]> maybe Zephyr can provide the SpiBus (typically a HAL provides SpiBus)
<TomB[m]> Zephyr doesn't support delays in there today
<adamgreig[m]> in which case embedded-hal-bus can generate SpiDevices from an SpiBus using an OutputPin and any struct that implements Delay
<adamgreig[m]> in the worst case, you can panic on a Operation::Delay, which is what NoDelay from embedded-hal-bus does, and then it just won't work with drivers that require delays inside transactions
<adamgreig[m]> ideally zephyr could learn to have a delay in the middle of a transaction like linux, since the reason we have it is various devices people were writing drivers for required it
<adamgreig[m]> but the majority of drivers shouldn't need or use it
<adamgreig[m]> I suspect that, like linux, zephyr could provide an SpiBus one way or another, and a DelayNs impl (i.e. a generic blocking delay), and then the embedded-hal-bus types can provide a fully featured SpiDevice
<thejpster[m]> How is the merge queue for cargo-binutils doing merges when the CI actions are failing? Like in https://github.com/rust-embedded/cargo-binutils/pull/137?
<burrbull[m]> NoDelay is not the best name for panic as for me.
<adamgreig[m]> I don't think anyone's looked in any detail into how compatible zephyr is with the new SPI traits though, so it would be very interesting to understand what parts of it are hard or impossible to implement
<JamesMunns[m]> burrbull[m]: `NoDelaysOrElse`
newam[m] has joined #rust-embedded
<newam[m]> thejpster[m]: The failing checks are not required under the branch permissions
<adamgreig[m]> it's passed in where something asks for a Delay provider, like NoDma and NoSck and that sort of thing, so I think it usually makes sense in context https://docs.rs/embedded-hal-bus/0.1.0-rc.2/embedded_hal_bus/spi/struct.NoDelay.html
edm has joined #rust-embedded
<thejpster[m]> newam: that seems ... suboptimal
<newam[m]> Yeah :(
<thejpster[m]> do we have guidelines on how to configure Github actions and merge queues and stuff?
<therealprof[m]> Have merge queues ever seemed optimal?
<thejpster[m]> opinions may vary on where the bar should be set, but we probably should have some minimal acceptable practices for running github repos within /rust-embedded and we should try and get all repos up to that level.
<adamgreig[m]> this is no different to when bors.toml had the wrong status checks written in it causing problems, not specific to merge queues
<therealprof[m]> We had guidelines for bors but I don't think we've 100% equivalent ones for MQ.
<adamgreig[m]> with the annoying difference being that the configuration is in the repo settings, not in a file inside the repo
<newam[m]> Yeah, it's annoying since you can't PR the changes, and you need a repo admin to set them.
<newam[m]> Also the required checks can change when for example the MSRV changes.
<newam[m]> I've seen some workarounds with a check that requires all others as a dependency and having that be the sole required check, causes a bit of latency though
<adamgreig[m]> that's precisely what the repo currently has
<therealprof[m]> Hm, I thought the guidelines were under https://github.com/rust-embedded/wg/tree/master/ops but doesn't look like it.
<newam[m]> Ah, I missed that
<adamgreig[m]> but I can't tell if it's just been fixed since that PR was merged, or if that PR was merged while the settings were like this and so something subtle is wrong
<therealprof[m]> Gotta run... 👋
<adamgreig[m]> but haven't been updated for GHMQ
<adamgreig[m]> I don't know how much it would help though... I don't want to write out the github documentation, which is the reference, and there are lots of ways different crates might want to use CI
<adamgreig[m]> the rule is presumably "you should have CI and it should make sure you don't merge PRs without it passing", which is also the intent in binutils, but there is (or was...) some bug in the setup that needs (or needed) fixing
<adamgreig[m]> ideally that would be in a separate document to "post-transfer" which is kinda a confusing place :P
<JamesMunns[m]> "next generation architecture (introduced 15 years ago)"
<adamgreig[m]> Tom B: did that make any sense? I hope it's somehow possible for zephyr to allow e-h spi drivers to work or we have a problem, but I sort of assume it could at a minimum work where it provides the SpiBus and then a "normal" blocking delay provider can do the delay
<TomB[m]> adamgreig[m]: I think it'd work fine, but I don't think it'd ever support Delay in transactions like that
<TomB[m]> * like that, so excluding support of Delay its a pretty close match up actually
<adamgreig[m]> I mean: in one way of providing support, zephyr never knows about SpiDevice or Operation or Operation::Delay
<adamgreig[m]> it provides the SpiBus trait which just has exchange() and no transaction/operations/delays
<TomB[m]> adamgreig[m]: zephyr does know about SpiDevice though, there's a struct that manages cs, clock settings, cs delays, etc
<TomB[m]> > <@adamgreig:matrix.org> I mean: in one way of providing support, zephyr never knows about SpiDevice or Operation or Operation::Delay
<TomB[m]> * zephyr does know about an equivalen tSpiDevice though, there's a struct that manages cs, clock settings, cs delays, etc
<TomB[m]> * know about an equivalent SpiDevice though,
<adamgreig[m]> something else uses SpiBus and an OutputPin and a Delay to provide SpiDevice, which can implement the Operation::Delay
<adamgreig[m]> but yea, I suspect that, as with linux, ideally zephyr provides the SpiDevice directly for most users (since it probably comes from the device tree too?)
<adamgreig[m]> and if there's no way to have a delay inside a transaction there, then the zephyr spidevice provider would have to just panic on delay, and for users that need a delay they can go via SpiBus perhaps?
<TomB[m]> that's just the not the way the API works, https://docs.zephyrproject.org/latest/hardware/peripherals/spi.html#c.spi_transceive
<TomB[m]> you give it a spi config, an array of things to do, and it goes and does them
<adamgreig[m]> is there any other direct/raw/not-CS-mediated access to the bus?
<TomB[m]> the array of things to do, much like e-h holds read/writes (transceives are done by matching reads/writes)
<TomB[m]> no there is not
<adamgreig[m]> if not, you can still just reuse one fake cs pin, do one transfer per transaction, and provide SpiBus
<adamgreig[m]> same as on linux with spidev
<adamgreig[m]> but it's a bit annoying
<TomB[m]> adamgreig[m]: No, because how would mutual access work then, every spi_transaction call is guaranteed exclusive access in zephyr, there's a semaphore all threads pend on
<TomB[m]> > <@adamgreig:matrix.org> is there any other direct/raw/not-CS-mediated access to the bus?
<TomB[m]> * No, because how would mutual access work then, every spi\_transaction call is guaranteed exclusive access in zephyr, there's a semaphore all threads pend on for that device
<adamgreig[m]> you would have to only do this on a physical bus that only has one device in the devicetree
<adamgreig[m]> (same as on linux)
<adamgreig[m]> wonder what people on zephyr do for drivers that do need a delay in a transaction though
<TomB[m]> 60k prs and issues, no one has asked for it that I'm aware of
<TomB[m]> * 60k+ prs, * and issues, dozens of socs, 100's of spi device drivers... no one
<adamgreig[m]> perhaps they found they couldn't do it and gave up :P who knows
<adamgreig[m]> anyway, I guess there's no nice way to add that to the current API since there's nothing beyond a list of matched tx/rx buffers
<adamgreig[m]> anyway, it sounds like for the time being just panicking on delay is probably the best you can do, and document that's what it does, and it should be fine for the majority of use cases
<adamgreig[m]> I worry some drivers will abuse this delay to provide cs-to-clock delays and then you will be in annoying situation of being able to support such things in the OS API but it not quite lining up with the rust drivers
<adamgreig[m]> a future problem
<adamgreig[m]> ok, that's all for the meeting at least, thanks everyone!
<adamgreig[m]> <thejpster[m]> "do we have a good sense of..." <- I'm not sure. a lot of what we have now was invented during the days before MaybeUninit or really any handle on where `static mut` caused problems, so there's a mix of possible solutions
<adamgreig[m]> the best thing would be to somehow have c-m-rt learn how to initialise other sections in the startup code, I think
<adamgreig[m]> but failing that, MaybeUninit seems to work?
<adamgreig[m]> I guess for now just updating the example in the docs to use MaybeUninit might help steer people in a good direction (or at least, away from the cliff edge)
<therealprof[m]> <TomB[m]> "60k prs and issues, no one has..." <- I have the same impression that it's rather niche.
explodingwaffle1 has quit [Quit: Idle timeout reached: 172800s]
chrysn[m] has joined #rust-embedded
<chrysn[m]> s/her/here/
<chrysn[m]> I'm probably late for the AOB/announcements part of the meeting (Tuesday 1900CET doesn't work well for me this year), but this could be of interest to more her:
<chrysn[m]> There is a strong effort to reverse engineer the ESP32 WiFi peripherals at <https://zeus.ugent.be/blog/23-24/open-source-esp32-wifi-mac/>. This could be an interesting thing for those who want to work with a Rust WiFi stack, eventually.
jessebraham[m] has joined #rust-embedded
<jessebraham[m]> Being able to build `esp-wifi` with no blobs would rule so hard
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
<chrysn[m]> What they aim for in the first iteration is that the blob would be relegated to setup time; the endgame is to remove it completely.
dsmith-work has quit [Quit: Leaving]
IlPalazzo-ojiisa has joined #rust-embedded
<dirbaio[m]> so, embedded-hal has some crates set to MSRV 1.56 due to edition 2021, others set to MSRV 1.60 due to using dep: namespaced features
<dirbaio[m]> but it turns out you can't cargo +1.56 check a MSRV 1.56 crate, because Cargo tries to parse the workspace and sees the dep: in the other crates
<dirbaio[m]> I guess this won't be an issue once it's released on crates.io because there's no workspace...??
<dirbaio[m]> but it makes CI a pain
<dirbaio[m]> plus there's only 2 crates without dep:: embedded-can and embedded-hal-nb
<dirbaio[m]> so maybe we should set everything to MSRV 1.60? (and 1.75 for async stuff)
<dirbaio[m]> like
<dirbaio[m]> set rust-version field to 1.56, but make README say MSRV is 1.60 and only test 1.60 in CI
<dirbaio[m]> readmes already say 1.60 🤔
<adamgreig[m]> if it's just e-can and e-hal-nb i'd be tempted to make them all 1.60?
<adamgreig[m]> odds are pretty good you end up needing the others too
<dirbaio[m]> setting rust-version to 1.60 actively forbids compilation on 1.56-1.59
<dirbaio[m]> artificially forbidding compilation for no reason felt a bit odd to me, this is why https://github.com/rust-embedded/embedded-hal/pull/490 put 1.56 on crates that can
<dirbaio[m]> hence the idea of putting rust-version = 1.56 but documenting MSRV is 1.60
<dirbaio[m]> like, you can try buliding on 1.56 and it'll likely work but it's not "supported"
<vollbrecht[m]> dirbaio[m]: does it mean a user cant set a simple flag to compile anyway? how big is the hurdle here concretely ?
<dirbaio[m]> ```
<dirbaio[m]> [dirbaio@mercury embedded-can]$ cargo +1.56 check
<dirbaio[m]> error: package `embedded-can v0.4.1 (/home/dirbaio/embedded-hal/embedded-can)` cannot be built because it requires rustc 1.60 or newer, while the currently active rustc version is 1.56.1
<dirbaio[m]> no flag to continue anyway AFAIK
<vollbrecht[m]> and for build the same? is that a "cargo" feature or a rust one? :D
<dirbaio[m]> cargo
<dirbaio[m]> yeah build falis too
<dirbaio[m]> and building a crate that depends on it fails too
<vollbrecht[m]> time to use rustc with make 💀
StephenD[m] has joined #rust-embedded
<StephenD[m]> :3