<re_irc>
<@mehmet:grusbv.com> I have a rather amateur question. I would like to have an instance of an initialized device driver to be an argument inside an embassy task.
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
fabic_ has quit [Quit: Leaving]
<re_irc>
<@dkhayes117:matrix.org> adamgreig: I think chapter 7 in the microbit discovery book needs to get rid of the consts in `heapless::{consts, vec}` and change `let mut buffer: Vec<u8, consts::U32> = Vec::new();` to `let mut buffer: Vec<u8, 32> = Vec::new();`
crabbedhaloablut has quit [Quit: No Ping reply in 180 seconds.]
crabbedhaloablut has joined #rust-embedded
Abhishek_ has joined #rust-embedded
Amadiro has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> ah, I guess heapless wasn't using const generics when that part was written
adamgreig is now known as agg
<re_irc>
<@dkhayes117:matrix.org> I can submit a pr if needed
<re_irc>
<@adamgreig:matrix.org> go for it, thanks!
starblue1 has quit [Ping timeout: 250 seconds]
<re_irc>
<@dimpolo:matrix.org> Hi everone.
<re_irc>
<@dimpolo:matrix.org> I wanna set up a global allocator for a STM32 chip and I'm slowly going mad over here because I just can't seem to find a single example of what needs to be done to reserve a heap section in RAM.
<re_irc>
<@dimpolo:matrix.org> Could someone please point me to an example memory.x file with a heap section defined.
<re_irc>
<@dimpolo:matrix.org> Big thanks from my sanity!
<re_irc>
<@newam:matrix.org> I don't think you need to explicitly define a heap section in `memory.x` (if you're using `cortex-m-rt` as the runtime anyway)
<re_irc>
<@adamgreig:matrix.org> it's soo exciting
<re_irc>
<@adamgreig:matrix.org> I think we will be bumping the MSRV for cortex-m and cortex-m-rt not long after, heh
<re_irc>
<@dkhayes117:matrix.org> No doubt!
<re_irc>
<@adamgreig:matrix.org> excited for, and slightly dreading, an explosion of cool libraries on crates.io that all use wild inline asm
<re_irc>
<@adamgreig:matrix.org> I mean we already have them but the effort of setting up precompiled binaries or requiring nightly presumably puts some people off
<re_irc>
<@newam:matrix.org> it will be fun for RTOS' that's for sure.
<re_irc>
<@adamgreig:matrix.org> heck it unlocks a lot of interesting options for just cortex-m-rt too
<re_irc>
<@adamgreig:matrix.org> hoist the startup asm into global_asm and it can now be configured with cargo features at least, things like turning on writing to vtor or sp at startup if required
<re_irc>
<@adamgreig:matrix.org> more sophisticated, use your build.rs script to call cortex-m-rt methods to set up new sections that can be initialised at reset etc too
<re_irc>
<@adamgreig:matrix.org> right now anything besides bss and data won't get set up, and they have to be contiguous...
<re_irc>
<@adamgreig:matrix.org> not that we can't do this today, but you could imagine generating memory.x from details in the build script that way too, might be more convenient for a lot of use cases
<re_irc>
<@adamgreig:matrix.org> (a lot of people are still going to want to write linker scripts themselves no doubt, but I bet more people just want to add a few new sections or something)
<re_irc>
<@vale_:matrix.org> hello everyone, I recently got a bit frustrated with pointer provenance and how unclear the exact requirements are to me. I'm writing the following page table code. `VirtAddr` and `PhysAddr` are wrappers around `usize` memory addresses and `l1_tables` is an array of `PhysAddr`s which point to memory regions contiguously allocated with my page allocator. said allocator can be found at...
<re_irc>
<@newam:matrix.org> Ah, thanks for the correction, learned something new.
<re_irc>
<@adamgreig:matrix.org> Wow I didn't know the docs had an explanation of it though, handy
<re_irc>
<@adamgreig:matrix.org> Lots of this is just "what does llvm say" and then it also doesn't say anything lol
<re_irc>
<@adamgreig:matrix.org> vale_, some people here may be able to help but it could be worth asking on the zulip
<re_irc>
<@vale_:matrix.org> I see. will try that then, thanks for the answers
<re_irc>
<@newam:matrix.org> If you just want a workaround you could calculate the pointer in a `usize` then cast to the target type.
<re_irc>
<@newam:matrix.org> Also for MMU table traversal I think there's some fairly robust code in the raspberry pi OS tutorials (may not may not be relevant for you)
<re_irc>
<@vale_:matrix.org> I mean ultimately my goal is to understand the subject of provenance well enough to be actually confident about avoiding footguns with raw pointers when doing Rust. I don't think the code from the tutorial really fits my requirements as this project is a reimplementation of the Nintendo Switch's microkernel written in C++ and therefore strives for semantic equivalence :)
<re_irc>
<@vale_:matrix.org> adamgreig: thanks, will give those a read!
<re_irc>
<@newam:matrix.org> adamgreig: Oh boy, time to go look through some of my code that does exactly this 🥲
<re_irc>
<@adamgreig:matrix.org> The worst part is basically everything just works fine and does what you expect it should
<re_irc>
<@adamgreig:matrix.org> Like of course a pointer it just a 32 bit integer memory address right? right????
<re_irc>
<@adamgreig:matrix.org> But apparently not 😭
<re_irc>
<@adamgreig:matrix.org> It would be easier if getting it wrong made it not work, heh
<re_irc>
<@vale_:matrix.org> that's also something I'm wondering, what is the class of issues that would originate from getting it wrong?
<re_irc>
<@vale_:matrix.org> something that comes to mind is the archival of the r0 crate for this reason, but was that motivated from actual issues triggered by this or just giving the spec a closer read?
<re_irc>
<@adamgreig:matrix.org> Maybe a future version of llvm miscompiles due to a bad optimisation or something?
<re_irc>
<@adamgreig:matrix.org> We never observed problems with r0 but the problem there was more concrete as it created an aliasing &mut
<re_irc>
<@adamgreig:matrix.org> And wrote to it
<re_irc>
<@adamgreig:matrix.org> adamgreig: I only know enough to be worried, not to really say anything meaningful
<re_irc>
<@adamgreig:matrix.org> We have a similar problem today in svd2rust where it creates shared refs to memory mapped structs and the compiler would be allowed to insert dummy reads to them beyond the volatile ops we do, which could have side effects
<re_irc>
<@adamgreig:matrix.org> The conclusion there is we need to never create shared refs to mmio and thus also not use structs for peripherals like that, but also no observed problems and it's harder to change so not done yet
<re_irc>
<@adamgreig:matrix.org> But will be one day and in the meantime it's technically unsound for every PAC or whatever
<re_irc>
<@vale_:matrix.org> I feel like this is one of the biggest challenges rust-embedded as a whole currently has to face
<re_irc>
<@adamgreig:matrix.org> In practice day to day it just doesn't seem to matter
<re_irc>
<@adamgreig:matrix.org> (to be clear we do really want it clarified or explained or fixed)
<re_irc>
<@adamgreig:matrix.org> But it's not clear that it's a practical problem or that code will necessarily have to change
<re_irc>
<@adamgreig:matrix.org> (well the svd2rust thing is different and will, but there are a few different concepts that fix that, it's "just" the big breaking change to all the PACs to manage)
<re_irc>
<@adamgreig:matrix.org> adamgreig: Maybe this is naïve 🙃
<re_irc>
<@vale_:matrix.org> I'm certainly not knowledgeable to comment on whether of if it will ever turn into a practical issue but the lack of resources on the topic (while understandable) might give people a pretty hard time if it ever will
<re_irc>
<@vale_:matrix.org> adamgreig: I understand your perspective, what I want to say is that provenance, should it turn into a practical issue some day, is not only one the ecosystem would be facing but also every individual who is doing embedded Rust. I feel like more guidelines on the matter would commonly help dealing with it more correctly at that point
<re_irc>
<@adamgreig:matrix.org> I'm hopeful the unsafe code guidelines will provide good guidance on it
<re_irc>
<@adamgreig:matrix.org> The issue is very similar in C and C++ I think, but somehow they get by. Bigger fish to fry I suppose
<re_irc>
<@vale_:matrix.org> definitely haha
<re_irc>
<@tholmie:matrix.org> adamgreig: This'll make v0.8 more useful to more people!
starblue1 has quit [Ping timeout: 250 seconds]
starblue1 has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> In theory no reason it couldn't be a 0.7 release but maybe a good excuse to work out 0.8