<astapleton[m]>
<astapleton[m]> "I just ran into a problem I..." <- I'm less confident in this diagnosis now: the failure still happens, it just suddenly started happening less frequently, with or without this "fix". Yay hardware.
sroemer has joined #rust-embedded
ivche_ has joined #rust-embedded
ivche has quit [Ping timeout: 252 seconds]
ivche_ is now known as ivche
Foxyloxy has quit [Read error: Connection reset by peer]
pcs38 has joined #rust-embedded
chrysn[m] has quit [Quit: Idle timeout reached: 172800s]
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
KevinPFleming[m] has quit [Quit: Idle timeout reached: 172800s]
rainingmessages has quit [Quit: Ping timeout (120 seconds)]
<KevinPFleming[m]>
U007D[m]: It may be important that the `write` methods are not read-modify-write, they are just plain write, so all other bits in those registers are likely being set to zero.
<JamesMunns[m]>
I honestly think that we might want to have svd2rust/chiptool rename `write` to `overwrite` or even spookier `write_with_defaults_plus` or something more verbose, and maybe push people towards `modify`. I feel like it's been a 7 year footgun
<JamesMunns[m]>
write/modify/read are perfectly fine names theoretically, but if people keep stubbing their toes, at some point you gotta shave down the stair or something :D
<U007D[m]>
JamesMunns[m]: Yeah, it's a tough problem. I also think they are already well-named; I had it in my mind that `write` did the RMW that `modify` does, although I've used `modify` since forever. Maybe a lint?
danielb[m] has joined #rust-embedded
<danielb[m]>
The writer in write could be a wrapper that requires you to call w = w.reset_to_defaults() or you'll not have access to the fields
<danielb[m]>
it would be absolutely obnoxious but overly obvious as well
<jason-kairos[m]>
<JamesMunns[m]> "I honestly think that we might..." <- I've been bitten by this probably about 10 times in the past year.
<jason-kairos[m]>
<danielb[m]> "The writer in write could be a..." <- That is the correct way to do it
<jason-kairos[m]>
* past year. Lost more hours than I care to admit.
<jason-kairos[m]>
* past year. Lost more hours than I care to admit debugging.
<U007D[m]>
jason-kairos[m]: +1
<U007D[m]>
* a lint? Or rename it `clobber`--that would get the point across 😆
<JonathanKeller[m>
<JamesMunns[m]> "I honestly think that we might..." <- svd2pac calls it `init`, which is concise and avoids the footgun nicely IMO -- it forces you to think "do I want to initialize the register or modify it?" rather than just defaulting to `write`
<U007D[m]>
<dirbaio[m]> "> <@u007d:matrix.org> I changed..." <- I'm not calling `embassry_rp::init()` anywhere, but I have a sneaky suspicion that it is being reset somehow. The `SOURCE` register is indeed 0 by the time my app is running.
<U007D[m]>
s/sneaky/sneaking/
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
write is nice when the hardware guarantees you don't need to guard the RMW with a critical section for something like gpio write (as there is a write and toggle register)
<U007D[m]>
* I'm not calling `embassry_rp::init()` anywhere, but I have a sneaking suspicion that it *is* being reset somehow. The `SOURCE` register is indeed 0 by the time my app is running.
<U007D[m]>
I'll hunt it down... 🔍️
<i509vcb[m]>
Although reserved bits can be a pain with write
<i509vcb[m]>
Which would make me think that write could be unsafe?
<U007D[m]>
* I'm not calling `embassry_rp::init()` anywhere, but I have a sneaking suspicion that it _is_ being reset somehow. `TIMER0`'s `SOURCE` register is indeed 0 by the time my app is running, where I should be setting it to 1 in `pre_init()`...
<U007D[m]>
I'll hunt it down... 🔍️
<U007D[m]>
* I'm not calling `embassry_rp::init()` anywhere, but I have a sneaking suspicion that it _is_ being reset somehow. `TIMER0`'s `SOURCE` register is indeed 0 by the time my app is running, where I (think I) am setting it to 1 in `pre_init()`...
<U007D[m]>
I'll hunt it down... 🔍️
<U007D[m]>
* I'm not calling `embassry_rp::init()` anywhere, but I have a sneaking suspicion that it _is_ being reset somehow. `TIMER0`'s `SOURCE` register is indeed 0 by the time my app is running, where I should be setting it to 1 in `pre_init()`...
<U007D[m]>
* I just double-checked. I'm not calling `embassry_rp::init()` anywhere, but I have a sneaking suspicion that it _is_ being reset somehow. `TIMER0`'s `SOURCE` register is indeed 0 by the time my app is running, where I should be setting it to 1 in `pre_init()`...
<U007D[m]>
I'll hunt it down... 🔍️
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
Is there any way to get the latest rp235x-hal working with pio 0.3.0?
<sourcebox[m]>
If I switch back to pio 0.2.0, I get could not find pio_fileinpio`, so I guess it was added later.
<sourcebox[m]>
Ok, the macro is there in pio-proc in the earlier versions.
jannic[m] has joined #rust-embedded
<jannic[m]>
I was sure I already opened a pull request for that, but it looks like I didn't. But I found a local branch that looks like it could work :-)
<jannic[m]>
jannic[m]: Let's move with that topic to https://matrix.to/#/#rp-rs:matrix.org so we don't disturb the meeting)
<adamgreig[m]>
ok, let's start! just a few things from me this week, first off is the member cleanup where we're still waiting for a response from Yuhan Lin almindor Henk nchong-at-aws newam on https://github.com/rust-embedded/wg/issues/832 (but otherwise thank you for lots of quick responses!)
<adamgreig[m]>
I understand the comment from @Kobzol is now being put on hold until after rustweek when we hopefully get closer to working out what's going on with the wg and the rust project
<adamgreig[m]>
and talking of which, I expect no meeting next week due to rustweek, though we'll report back on matrix the week after
<adamgreig[m]>
an other announcements from anyone?
therealprof[m] has joined #rust-embedded
<therealprof[m]>
adamgreig[m]: Where is that comment?
<adamgreig[m]>
https://github.com/rust-embedded/cortex-m/pull/596 on adding unsafe to the link_section emitted by the macros, though I thought this wasn't necessary due to how editions work but maybe it is
<adamgreig[m]>
therealprof[m]: I don't have a link handy atm but it's in the embedded stream. the gist is that there's no point putting a bunch of effort into rejigging repo administration right now when there's an open question about whether the wg stays inside the project or not
<adamgreig[m]>
I don't have any other points for this week, so open to anything else anyone wants to bring up, otherwise we can have a short meeting
<therealprof[m]>
adamgreig[m]: Yes, found it via the link you provided.
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
adamgreig[m]: `riscv` is going through a similar deprecation process, potentially for the same reasons. I'm still unclear on where the reasoning for Rust code being unsound before RAM init comes from. I saw some discussion of the unstable Rust ABI being a potential cause of unsoundness when calling directly from `asm`. Is there an (semi-)official document that explains when it is first sound to call Rust code on baremetal?
<JamesMunns[m]>
<adamgreig[m]> "otherwise there are a couple..." <- > I'm still unclear on where the reasoning for Rust code being unsound before RAM init comes from.
<JamesMunns[m]>
<adamgreig[m]> "otherwise there are a couple..." <- I can expand on that part if you'd like!
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Presumably the compiler assumes BSS will be zeroed?
<adamgreig[m]>
and statics initialised, yea
<JamesMunns[m]>
yep, basically, rust assumes statics will already have the "right" values, either zero or initialized
<rmsyn[m]>
bartmassey[m]: isn't BSS zeroed by linker magic?
<adamgreig[m]>
a lot of this stuff isn't spelled out in an official rust document that says this must be true or it's immediately UB
<JamesMunns[m]>
nope, it's zeroed by code before main
<adamgreig[m]>
but instead you have to sort of infer from what is known about what rust assumes to be true
<JamesMunns[m]>
but importantly code that runs AFTER pre_init, and BEFORE main
<adamgreig[m]>
so in practice you might find it's fine, but certainly if your pre_init interacted with any statics at all, you'd be in deep trouble
<bartmassey[m]>
Unless the statics were defined by assembly and externed.
<adamgreig[m]>
and in theory just the code existing in the rust vm means the compiler might decide to read the static for fun and thus be in trouble
<JamesMunns[m]>
also, statics can be more than explicit static values
<adamgreig[m]>
(albeit maybe not in practice a problem)
<JamesMunns[m]>
I think the optimizer can promote certain values to statics?
<adamgreig[m]>
the thing about not calling rust functions from asm (and that therefore specifically main and interrupt handlers should be extern C) I'm not sure about
<adamgreig[m]>
but it's in principle true that the rust abi is undefined and could change
<rmsyn[m]>
adamgreig[m]: right, I have run into that problem, had random garbage in statics because I didn't clear BSS properly
<rmsyn[m]>
so, unless we could use some lint magic in the proc macro for pre_init to ensure no statics are used, we can't guarantee soundness for Rust code?
<JamesMunns[m]>
yeah, imo it should just be assembly. This is in the area of "things the compiler/optimizer assumes must be true for the abstract model to be sound"
<thejpster[m]>
Accessing them isn’t required. The mere existence of a bool with a value that isn’t 0 or 1 is insta UB.
<therealprof[m]>
fasterthanlime had some articles about that topic...
<JamesMunns[m]>
(C has the same requirements, for the record!)
<adamgreig[m]>
whether that UB is observable probably depends on whether anything interacts with the static, but yea, by the rules, it's not allowed, hence no rust "before main"
<JamesMunns[m]>
And for splitting hairs, it's not that Rust can't do it, it's that a rust program can't do it FOR ITSELF.
<JamesMunns[m]>
You could have a bootloader/os that does it for the app, with no asm required for starting the app
<JamesMunns[m]>
but "a program" can not "initialize its own environment"
<JamesMunns[m]>
because Rust (and C) have "environmental requirements" for things that must be true, and provided "by the platform"
<JamesMunns[m]>
which can be ASM, a bootloader, etc.
<JamesMunns[m]>
(because ASM has no "environmental requirements" to be sound!)
<rmsyn[m]>
alright, so depending on the platform, this setup may be performed by the ROM bootloader provided by the vendor?
<bartmassey[m]>
Can a bare inline assembly function can do pre_init tho? In practice this seems quite safe, but in principle maybe no?
<JamesMunns[m]>
yep, could be!
<adamgreig[m]>
I don't think I've seen any ROM bootloaders that do it though
<JamesMunns[m]>
bartmassey[m]: I'm not certain what requirements Rust makes on inline_asm
<adamgreig[m]>
they'd need to know what part of your ram was bss and what was statics and where those statics came from
<rmsyn[m]>
also, does cortex-m have an example of a pre_init asm implementation? think it would be good to provide one for riscv, too
<JamesMunns[m]>
pre_init is "user provided"
<adamgreig[m]>
bartmassey[m]: I think a naked function could but probably not a normal function that happened to just have an inline_asm block
<bartmassey[m]>
Things that load ELF know enough to do the right thing if they choose to.
<JamesMunns[m]>
you don't NEED one
<JamesMunns[m]>
the crt0 behavior is provided as asm in cortex-m-rt, that's the only thing that "has" to be done
<adamgreig[m]>
bartmassey[m]: yea, if the rom bootloader loaded an elf from flash it could, but i've not seen that either :P
<JamesMunns[m]>
pre_init is for if you need to do stuff like setup clocks or watchdogs before bss/data is initialized, like if you have external RAM you want zeroed by cortex-m-rt
<thejpster[m]>
I have a __pre_init for the S32Z2. I needed to initialise the ECC RAM by writing 64 bit zeroes to all of it.
<thejpster[m]>
I wrote it in assembly using global asm.
<therealprof[m]>
adamgreig[m]: It used to be the norm to do XiP before devices started to be flooded with NAND.
<adamgreig[m]>
but even with xip was it loading elfs?
<therealprof[m]>
Yes.
<adamgreig[m]>
thejpster[m]: in c-m-rt we have a cargo feature to zero the ram, for the same reason
<adamgreig[m]>
therealprof[m]: huh, weird, for bare-metal programs? what chip? sounds fun/annoying
<bartmassey[m]>
Got to run — class. See some of you in NL soon!
<adamgreig[m]>
see you next week!
<therealprof[m]>
adamgreig[m]: e.g. u-boot has ELF support
<thejpster[m]>
cortex-r-rt doesn’t have that feature (yet)
<JamesMunns[m]>
therealprof[m]: it's turtles all the way down, I'm afraid
<thejpster[m]>
therealprof[m]: Neotron OS also has an ELF loader that initialises globals. Just like ld on Linux.
<therealprof[m]>
adamgreig[m]: I don't recall which platform that was, most likely some MIPS r4 based chips from Infineon.
<therealprof[m]>
s/r4/r4k/
<adamgreig[m]>
fun
<adamgreig[m]>
well, if that's all for this week, let's finish there, thanks everyone! see some of you next week at RustWeek and otherwise back here in two weeks
<thejpster[m]>
(I’m looking for a reference that says non initialised statics are insta UB and I can’t find one)
PatrickLloyd[m]1 has joined #rust-embedded
<PatrickLloyd[m]1>
Has anyone here played with https://rust-hdl.org/ / has some FPGA background?
<PatrickLloyd[m]1>
I am exploring building an emulation / co-simulation framework in Rust (kind of like Renode + Verilator) and wanted to get some input on it
<thejpster[m]>
Part of the issue is that doing it in Rust involves getting the address of a u32 from the linker and then writing well beyond the bounds of that u32.
<JamesMunns[m]>
Oh this is sort of related wrt simulation (but very far from what Patrick mentioned), I think it would be very cool for us to spend some time playing https://github.com/Patryk27/kartoffels at RustWeek
<JamesMunns[m]>
It's a gamified simulator of a very slow rv32 processor, BUT it's basically "embedded rust, the training game"
<JamesMunns[m]>
some folks have even gotten embassy ported to it
<JamesMunns[m]>
CC @bartmassey for training/teaching reasons when you're done with class :D
<PatrickLloyd[m]1>
JamesMunns[m]: This looks really fun haha
<JamesMunns[m]>
Gotta run, have a good week all :D
burrbull[m] has joined #rust-embedded
<burrbull[m]>
<PatrickLloyd[m]1> "Has anyone here played with..." <- not as an advertisement. There is also another similar project someone have found https://git.libre-chip.org/libre-chip/fayalite
<KevinPFleming[m]>
Is there a no_std-friendly crate similar to anyhow that doesn't require a global allocator?
<KevinPFleming[m]>
I've got a function which needs to be able to return either an embassy_stm32::usart::Error or its own custom Error type.
<JamesMunns[m]>
thiserror is no-std
<JamesMunns[m]>
ive not used it personally in no-std, but it works for that in std land
pcs38 has quit [Quit: leaving]
ivche has quit [Ping timeout: 276 seconds]
ivche has joined #rust-embedded
Foxyloxy has joined #rust-embedded
<xnor>
I'm getting to the point in a project where I'm wondering if I shoudl be using some sort of GUI toolkit. I am rendering using embedded_graphics and I've created a variety of displays, mostly just text but a few simple widgets. My display is pretty small and one thing that I'm running into is some text not fitting on screen horizontally, so i'm wondering about some sort of marquee animation..
<xnor>
anyway, I'm sort of curious about ratatui (I'm using embedded_graphics but i'm on a linux device with std) but i'm wondering if folks have other suggestsions for toolkits for mostly textual display/layout
<dngrs[m]>
(side note: anyhow isn't that great for custom errors/library usage, even in std land; I see it more as a top level catch all, something you'd not expose, as a rule of thumb)