08:32 <re_irc> <@henkkuli:matrix.org> You can make it work if you add () around the unsafe block:

08:32 <re_irc> <@henkkuli:matrix.org> ```rust

08:32 <re_irc> <@henkkuli:matrix.org> (unsafe { p.read() }) != 0xFFFF

08:33 <re_irc> <@henkkuli:matrix.org> (unsafe { p.read() } != 0xFFFF)

08:33 <re_irc> <@henkkuli:matrix.org> You can even wrap the whole thing in parenthesis:

08:33 <re_irc> <@henkkuli:matrix.org> ```rust

08:35 <Lumpio-> There are some funny parsing rules wrt {} expressions from what I remember

08:35 <Lumpio-> Probably to avoid some ambiguous situation I can't immediately think of

11:19 <re_irc> <@peterstuart:matrix.org> ble

11:53 <re_irc> <@chmanie:matrix.org> I am planning to write a simple bootloader that - for now - just jumps to the user app code in memory and exectues it. I was wondering if there's a way to flash both the bootloader and the application code successively with cargo flash or probe-rs or whether I need to combine the two binaries somehow before flashing them at once. Sorry for the open question but I'm not really sure how to approach this, any...

11:54 <re_irc> ... pointers to some reading material would be appreciated! I found some examples for bootloaders but they always are used to flash the user code to the device (which makes sense but is not really what I'm after in the first instance)

11:57 <re_irc> <@diondokter:matrix.org> By default, probe-rs only erases the flash pages that are needed to write the firmware to. So if you make sure that the bootloader and the application don't share any same page, then you're just fine and don't need to do anything special. Just flash them both separately.

11:58 <re_irc> <@diondokter:matrix.org> chmanie

11:59 <re_irc> <@yatekii:matrix.org> the library itself should also support that you do not erase before flashing.

11:59 <re_irc> <@yatekii:matrix.org> cargo-flash/embed not

12:00 <re_irc> <@yatekii:matrix.org> dirbaio: uses that in production too :)

12:00 <re_irc> <@chmanie:matrix.org> Oh okay, got it, that seems pretty straightforward!

12:01 <re_irc> <@chmanie:matrix.org> Sorry to expand on this but as far as I understand it would just be about adjusting the start memory addresses of the two separate projects and flashing them successively

12:04 <re_irc> <@chmanie:matrix.org> I'm going to attempt this, thanks so far diondokter and Noah !

12:05 <re_irc> <@diondokter:matrix.org> chmanie:matrix.org: Correct 😁

12:05 <re_irc> <@diondokter:matrix.org> Oh and it is also smart to limit the size of the flash in the projects so they don't overlap

12:06 <re_irc> <@chmanie:matrix.org> Yes, good point

12:06 <re_irc> <@chmanie:matrix.org> Let's see what I can do, bootloaders seemed to be very daunting for me but it seems it's maybe not as bad as I thought

12:08 <re_irc> <@yatekii:matrix.org> chmanie:matrix.org: generally you always have to do this with a bootloader and an application binary which can update. because if you update the application and it overlaps into the bootloader you have to do some shenanigans.

12:08 <re_irc> <@yatekii:matrix.org> that's why normally you just ensure no overlap and all gucci :)

14:02 <re_irc> <@robtsuk:matrix.org> Hi! Is this a good place to ask about cross https://github.com/rust-embedded/cross ?

14:02 <re_irc> <@robtsuk:matrix.org> I tried yesterday to use it on my M1 MacBook Air and discovered it didn't work

14:02 <re_irc> <@robtsuk:matrix.org> I was hoping I could take a crack at fixing it, with some guidance

15:17 <re_irc> <@newam:matrix.org> robtsuk: this is the place to ask about cross :)

15:17 <re_irc> <@newam:matrix.org> I am not entirely up to date, but a month or two ago I remember there was a call for new maintainers.

15:17 <re_irc> <@newam:matrix.org> I unfortunately cannot offer guidance with the code, but there might be people here who can.

15:45 <re_irc> <@tonygarnockjones:matrix.org> robtsuk:matrix.org: What was the symptom?

16:24 <Lumpio-> I really hope everybody's not just fixing their projects to work on Apple's ARM CPUs specifically and all the work will pay off when other manufacturers jump on the bandwagon

16:46 <re_irc> <@chmanie:matrix.org> diondokter & Noah it's working! Thanks again for your help. Just flashing them succesively seems to work perfectly fine

17:53 <re_irc> <@yatekii:matrix.org> :)

18:20 <re_irc> <@newam:matrix.org> is there a way to do a `[patch.crates-io]` that applies only to a single crate within a workspace?

18:23 <re_irc> <@yatekii:matrix.org> I don't think so

18:23 <re_irc> <@yatekii:matrix.org> the dependencies are shared within the crate I think

18:23 <re_irc> <@yatekii:matrix.org> but isn't there a way to basically rename a dependency? maybe that way it works. not sure

18:24 <re_irc> <@yatekii:matrix.org> newam: https://github.com/rust-lang/cargo/issues/5653

18:24 <re_irc> <@yatekii:matrix.org> not sure if it will work but worth a try

18:24 <re_irc> <@newam:matrix.org> Maybe, we will see :D

21:15 <re_irc> <@sympatron:matrix.org> How do you ensure a value behind some reference is actually read from RAM and the read is not optimized away? I have something like this:

21:15 <re_irc> <@sympatron:matrix.org> struct Entry {

21:15 <re_irc> <@sympatron:matrix.org> }

21:15 <re_irc> <@sympatron:matrix.org> pub data: [u8; 8],

21:15 <re_irc> <@sympatron:matrix.org> pub flags: u32,

21:15 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/7d67916c38a24a4bd2901cb1a39b31730332d2edf731d8290b9849ee33fc95d7 (24 lines)

21:17 <re_irc> <@sympatron:matrix.org> I want to be sure `entry.flags` is actually read from memory. What would I have to do?

21:18 <re_irc> <@sympatron:matrix.org> Is it enough to have a compiler fence before the read?

21:39 <re_irc> <@jannic:matrix.org> AFAIK to guarantee a read is not optimized away, you need https://doc.rust-lang.org/core/ptr/fn.read_volatile.html