00:05 <re_irc> <thalesfragoso> dirbaio: Yeah, it favors the easy route, if you don't want to pass ownership then you do what you already have to do in the futures one

00:10 <re_irc> <thalesfragoso> It seems it doesn't require FusedFuture too, that looks a bit error prone though

00:31 <re_irc> <thalesfragoso> dirbaio: Can you ? These rules for extending the scope of temporaries are very confusing

00:31 <re_irc> <thalesfragoso> I thought it didn't work if it was used directly in function arguments

01:56 <re_irc> <thalesfragoso> Hmm, how come &UnsafeCell be derefereable ? Couldn't that cause data races ? Or derefereable doesn't mean race free ?

01:57 <re_irc> <thalesfragoso> +data

04:06 <re_irc> <Imran K> Hi all, I’m using "rp2040" pic board. I have written a simple led blinking program, but if I flash the binary file, the led does not blink. Does rp2040 support binary file?

04:20 <re_irc> <9names (@9names:matrix.org)> Try starting with https://github.com/rp-rs/rp2040-project-template, it's a safer way to get started with rp2040.

04:20 <re_irc> Also check the readme, should cover all the common ways of pushing new code onto a Pico.

04:26 <re_irc> <Imran K> 9names: Yeah it’s working, but I want flash binary format on the pico not executable format, because I'm writing a secure boot for "rp2040", so i want binary file for signature.

04:28 <re_irc> <Imran K> is this possible to flash binary format on the pico.

04:31 <re_irc> <Imran K> * binary format support

04:33 <re_irc> <9names (@9names:matrix.org)> It is possible to flash a binary file. How are you programming it now?

04:35 <re_irc> <Imran K> Yeah I can able to flash bin file using probe-rs-cli but led is not woking

04:36 <re_irc> <Imran K> * "probe-rs-cli" but led is not woking on pico.

04:37 <re_irc> <Imran K> * blinking

04:39 <re_irc> <Imran K> Executable format working.

04:41 <re_irc> <Imran K> This means binary format not support on the pico?

04:55 <re_irc> <9names (@9names:matrix.org)> I don't understand what you mean. An executable is a binary file.

04:55 <re_irc> How are you creating this bin file, what are you generating it from, which commands are you using to load it?

05:01 <re_irc> <Imran K> 9names: I’m converting elf to bin format using this command "rust-objcopy rp2040_blinky -O binary rp2040_blinky.bin"

05:24 <re_irc> <Lachlan> Perhaps your linker script is incorrect

05:30 <re_irc> <jspngh> I think the linker script should be okay if the elf file is working. But maybe you are passing the wrong address when flashing the bin file?

10:59 <re_irc> <henrikssn> Is there a safe way to hand out multiple mutable references in Rust to a variable without using locks and not hitting UB?

10:59 <re_irc> <henrikssn> I think I am looking for an equivalent of "volatile" in C

11:03 <re_irc> <K900> You probably want one of the "Atomic*" types then

11:08 <re_irc> <henrikssn> Doesn't the atomic types use different instructions than a volatile primitive in C?

11:08 <re_irc> <K900> Not necessarily

11:08 <re_irc> <henrikssn> E.g. would AtomicU32::load be equivalent to a read of a volatile uint32 in C?

11:08 <re_irc> <henrikssn> And same thing for store

11:09 <re_irc> <K900> That is not guaranteed

11:09 <re_irc> <K900> But "volatile" in C is also not guaranteed to be thread safe

11:09 <re_irc> <K900> Whereas atomics are

11:09 <Lumpio-> It depends on the architecture, one some architectures a 32-bit normal load might be atomic for example so load might do that

11:09 <Lumpio-> Does it matter if it uses different instructions?

11:10 <re_irc> <K900> I feel like you should really explain what you're _actually_ trying to do

11:10 <re_irc> <K900> Instead of what C feature you think will help you do it

11:13 <re_irc> <henrikssn> It has to do with DMA, and the underlying data might change at any time, so I want to prevent the compiler from caching it in registers

11:13 <re_irc> <K900> In that case you want "ptr::{read,write}_volatile"

11:13 <re_irc> <K900> Which are specifically designed for operating on I/O memory

11:14 <re_irc> <henrikssn> I assume there is no safe way of doing this?

11:15 <re_irc> <K900> There can't be, you're reading arbitrary pointers

11:15 <re_irc> <K900> You can use docs.rs/volatile which gives you a "safe" wrapper, but it's not _actually_ completely safe

11:16 <re_irc> <henrikssn> hmm

11:17 <re_irc> <henrikssn> assuming this is a u32 at a stable memory address

11:17 <re_irc> <henrikssn> how could a load/store be unsafe?

11:18 <re_irc> <K900> Lots of caveats possible

11:18 <re_irc> <K900> Alignment

11:18 <re_irc> <K900> etc

11:22 <re_irc> <henrikssn> aha, ok, to reformulate the problem: Say that I have a struct that looks like this:

11:22 <re_irc> static mut foobar: FooBar = ...;

11:22 <re_irc> struct FooBar {

11:22 <re_irc> foo: u32,

11:22 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/39bd30ac58242a34b0db0c3a2848012de1975e7697ed4e1a64235ab2ac327823 (7 lines)

11:23 <re_irc> <henrikssn> I guess making them "AtomicU32" isn't completely solving this problem, right?

11:23 <re_irc> <henrikssn> aha, ok, to reformulate the problem: Say that I have a struct that looks like this:

11:23 <re_irc> #[repr(packed)]

11:23 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/8b089de895ea41bb1545026442b81d12d4e4526b7e1bf2847600e77ac2813152 (8 lines)

11:23 <re_irc> static mut foobar: FooBar = ...;

11:23 <re_irc> struct FooBar {

11:24 <re_irc> <henrikssn> With "Volatile" I assume I need to create a separate struct which contains volatile references to foo and bar

12:04 <re_irc> <henrikssn> After reading this thread, I believe the only way to do this is to use "ptr::read/write_volatile" and be very careful not to ever create a reference to any of the fields https://internals.rust-lang.org/t/volatile-and-sensitive-memory/3188/98

12:05 <re_irc> <henrikssn> The moment you create a reference, rust is free to assume that the data follows the aliasing rules (which it doesn't) and UB will happen

12:05 <re_irc> <henrikssn> +(may)

19:03 <re_irc> <Lachlan> I'm trying to figure out what dependency is trying to pull in the alloc crate since I've suddenly started getting "error: no global memory allocator found but one is required; link to std or add "#[global_allocator]" to a static item that implements the GlobalAlloc trait" when compiling our firmware.

19:03 <re_irc> <Lachlan> Anyone have any ideas?

19:03 <re_irc> <Lachlan> Been looking through recent changes and dependency features to see if anything stands out, but no

20:03 <re_irc> <dirbaio> doesn't exactly show what uses alloc, but maybe you can find out with "cargo tree --format '{p} {f}'" and then searching for what has "std" or "alloc" cargo features enabled

22:04 <re_irc> <adamgreig> henrikssn: yea, you can't have a reference open to something that dma will mutate in the background, so usually the approach is to swap buffers around so the user code interacts with one buffer while dma operates on another

22:14 <re_irc> <thalesfragoso> adamgreig: You can still use re-borrow semantics casting it to a *mut, pass it to a "FFI boundary" and do proper synchronization

22:14 <re_irc> <thalesfragoso> After the synchronization you can use the &mut again

22:15 <re_irc> <thalesfragoso> That's how you pass in buffer to the kernel, etc

22:15 <re_irc> <thalesfragoso> * buffers