<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?
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]>
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.
<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
<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:
<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
<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
<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]
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...
<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]>
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
<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]
<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.
<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.
<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]>
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.
<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?
<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
<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
<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
<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
<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]>
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]>
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