starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
edm has quit [Ping timeout: 245 seconds]
dreamcat4 has quit [Ping timeout: 260 seconds]
dreamcat4 has joined #rust-embedded
edm has joined #rust-embedded
edm has quit [Ping timeout: 258 seconds]
dreamcat4 has quit [Ping timeout: 258 seconds]
edm has joined #rust-embedded
dreamcat4 has joined #rust-embedded
fabic has joined #rust-embedded
jackneilll has joined #rust-embedded
jackneill has quit [Ping timeout: 258 seconds]
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter has joined #rust-embedded
fabic_ has joined #rust-embedded
fabic has quit [Ping timeout: 244 seconds]
fabic_ has quit [Ping timeout: 244 seconds]
<re_irc> <> You can make it work if you add () around the unsafe block:
<re_irc> <> ```rust
<re_irc> <> (unsafe { }) != 0xFFFF
<re_irc> <> (unsafe { } != 0xFFFF)
<re_irc> <> You can even wrap the whole thing in parenthesis:
<re_irc> <> ```rust
<Lumpio-> There are some funny parsing rules wrt {} expressions from what I remember
<Lumpio-> Probably to avoid some ambiguous situation I can't immediately think of
<re_irc> <> ble
<re_irc> <> 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...
<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)
<re_irc> <> 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.
<re_irc> <> chmanie
<re_irc> <> the library itself should also support that you do not erase before flashing.
<re_irc> <> cargo-flash/embed not
<re_irc> <> dirbaio: uses that in production too :)
<re_irc> <> Oh okay, got it, that seems pretty straightforward!
<re_irc> <> 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
<re_irc> <> I'm going to attempt this, thanks so far diondokter and Noah !
<re_irc> <> Correct 😁
<re_irc> <> Oh and it is also smart to limit the size of the flash in the projects so they don't overlap
<re_irc> <> Yes, good point
<re_irc> <> 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
<re_irc> <> 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.
<re_irc> <> that's why normally you just ensure no overlap and all gucci :)
fabic_ has joined #rust-embedded
unmanbearpig has quit [Ping timeout: 260 seconds]
fabic_ has quit [Ping timeout: 260 seconds]
<re_irc> <> Hi! Is this a good place to ask about cross ?
<re_irc> <> I tried yesterday to use it on my M1 MacBook Air and discovered it didn't work
<re_irc> <> I was hoping I could take a crack at fixing it, with some guidance
unmanbearpig has joined #rust-embedded
<re_irc> <> robtsuk: this is the place to ask about cross :)
<re_irc> <> I am not entirely up to date, but a month or two ago I remember there was a call for new maintainers.
<re_irc> <> I unfortunately cannot offer guidance with the code, but there might be people here who can.
fabic_ has joined #rust-embedded
<re_irc> <> What was the symptom?
starblue has quit [Ping timeout: 264 seconds]
<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
<re_irc> <> diondokter & Noah it's working! Thanks again for your help. Just flashing them succesively seems to work perfectly fine
emerent has joined #rust-embedded
fabic_ has quit [Ping timeout: 260 seconds]
<re_irc> <> :)
<re_irc> <> is there a way to do a `[patch.crates-io]` that applies only to a single crate within a workspace?
<re_irc> <> I don't think so
<re_irc> <> the dependencies are shared within the crate I think
<re_irc> <> but isn't there a way to basically rename a dependency? maybe that way it works. not sure
<re_irc> <> newam:
<re_irc> <> not sure if it will work but worth a try
<re_irc> <> Maybe, we will see :D
starblue has joined #rust-embedded
starblue has quit [Ping timeout: 258 seconds]
<re_irc> <> 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:
<re_irc> <> struct Entry {
<re_irc> <> }
<re_irc> <> pub data: [u8; 8],
<re_irc> <> pub flags: u32,
starblue has joined #rust-embedded
<re_irc> <> I want to be sure `entry.flags` is actually read from memory. What would I have to do?
<re_irc> <> Is it enough to have a compiler fence before the read?
<re_irc> <> AFAIK to guarantee a read is not optimized away, you need