rardiol has quit [Ping timeout: 256 seconds]
nohit has quit [Ping timeout: 240 seconds]
nohit has joined #rust-embedded
dreamcat4_ has joined #rust-embedded
VShell has joined #rust-embedded
ni_ has joined #rust-embedded
adamgreig has joined #rust-embedded
dreamcat4 has quit [Ping timeout: 240 seconds]
Shell has quit [Ping timeout: 240 seconds]
ni has quit [Ping timeout: 240 seconds]
dreamcat4_ is now known as dreamcat4
agg has quit [Ping timeout: 240 seconds]
VShell is now known as Shell
Foxyloxy has quit [Ping timeout: 256 seconds]
Foxyloxy has joined #rust-embedded
Socke has quit [Ping timeout: 240 seconds]
Socke has joined #rust-embedded
fabic has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
loki_val has quit [Ping timeout: 276 seconds]
ni_ is now known as ni
fabic has quit [Ping timeout: 240 seconds]
fabic has joined #rust-embedded
fabic_ has joined #rust-embedded
fabic has quit [Ping timeout: 250 seconds]
<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.
<re_irc> <@mehmet:grusbv.com> ```rust
<re_irc> <@mehmet:grusbv.com> #[embassy::task]
<re_irc> <@mehmet:grusbv.com> async fn refresh_acc_task(mut acc: IIS3DWB<SPI,CS>)
<re_irc> <@mehmet:grusbv.com> but in the DD SPI and CS is explicitly defined
<re_irc> <@mehmet:grusbv.com> /// Driver's implementation for given SPI and CS
<re_irc> <@mehmet:grusbv.com> impl<SPI, CS, E, PinError> IIS3DWB<SPI,CS>
<re_irc> <@mehmet:grusbv.com> ```rust
<re_irc> <@mehmet:grusbv.com> where
<re_irc> <@mehmet:grusbv.com> The latter definition indicates that I am missing a type parameter for SPI and CS
<re_irc> <@mehmet:grusbv.com> How can I indicate the type of IIS3DWB<SPI,CS> in a fn definition
<re_irc> <@k900:0upti.me> If you have a specific target, you can use the definitions from that
<re_irc> <@k900:0upti.me> If you don't, you'll have to make your task generic as well
<re_irc> <@mehmet:grusbv.com> I see, I am using the peripherals through embassy, so I will try to do that.
fabic_ has quit [Ping timeout: 250 seconds]
Foxyloxy has quit [Quit: Textual IRC Client: www.textualapp.com]
Foxyloxy has joined #rust-embedded
rardiol has joined #rust-embedded
rardiol has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
rardiol has joined #rust-embedded
rardiol has quit [Client Quit]
fabic_ has joined #rust-embedded
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> <@newam:matrix.org> That example _should_ just work
<re_irc> <@adamgreig:matrix.org> yea, cortex-m-rt just starts the heap above all your other allocations, and the stack grows towards it https://docs.rs/cortex-m-rt/latest/cortex_m_rt/fn.heap_start.html
<re_irc> <@dimpolo:matrix.org> Oh wow, that explains why I didn't find anything.
<re_irc> <@dimpolo:matrix.org> Thanks a lot!
<re_irc> <@dkhayes117:matrix.org> I wonder when inline assembly will be stable?
starblue1 has joined #rust-embedded
<re_irc> <@adamgreig:matrix.org> rust 1.59, in six weeks
<re_irc> <@adamgreig:matrix.org> someone has a nice website showing when the next rust release will be, but I don't remember the url...
<re_irc> <@newam:matrix.org> whatrustisit.com
<re_irc> <@adamgreig:matrix.org> that's it! thanks
<re_irc> <@dkhayes117:matrix.org> exciting :)
<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> <@vale_:matrix.org> .
<re_irc> <@vale_:matrix.org> ```rs
<re_irc> <@dkhayes117:matrix.org> adamgreig: Won't stable inline eliminate the need for pre-compiled binaries?
<re_irc> <@newam:matrix.org> vale_:matrix.org: I'm not 100% sure I am answering your question here.
<re_irc> <@newam:matrix.org> For add there are only 3 condition for undefined behavior to occur: https://doc.rust-lang.org/std/primitive.pointer.html#method.add
<re_irc> <@newam:matrix.org> > If any of the following conditions are violated, the result is Undefined Behavior:
<re_irc> <@newam:matrix.org> > Both the starting and resulting pointer must be either in bounds or one byte past the end of the same allocated object.
<re_irc> <@adamgreig:matrix.org> Unfortunately allocated object doesn't just mean heap here
<re_irc> <@vale_:matrix.org> ^ that I thought too. which makes it so complicated for me to reason about this
<re_irc> <@adamgreig:matrix.org> And is exactly the provenance problem when the pointers are magicked from integers
<re_irc> <@adamgreig:matrix.org> dkhayes117:matrix.org: It will indeed, a big help for c-m and c-m-rt
<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> <@adamgreig:matrix.org> newam:matrix.org: https://www.ralfj.de/blog/2020/12/14/provenance.html and https://github.com/rust-lang/unsafe-code-guidelines/issues/52 have some info on why this ends up being more complicated than it seems like it should be
<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> Biggest theoretical challenge anyway?
<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
xnor has quit [Ping timeout: 240 seconds]