jasperw has joined #rust-embedded
starblue1 has joined #rust-embedded
<re_irc> <@n​ewam:m​atrix.org> is there a way to have a feature with the same name as an optional dependency?
<re_irc> <@n​ewam:m​atrix.org> [features]
<re_irc> <@n​ewam:m​atrix.org> I want to do something like this:
<re_irc> <@n​ewam:m​atrix.org> ```toml
starblue has quit [Ping timeout: 268 seconds]
<re_irc> <@w​illeml:m​atrix.org> So I got my code to compile, and the mcu does connect to USB and sends the correct info, but I don't think that it is actually sending movements, code: https://github.com/willemml/joystick-rs/blob/master/src/main.rs
fabic has joined #rust-embedded
<re_irc> <@w​illeml:m​atrix.org> Does there need to be delays between sending mouse reports or something? Do I need to use interrupts?
emerent has quit [Ping timeout: 245 seconds]
emerent has joined #rust-embedded
<re_irc> <@b​urrbull:m​atrix.org> newam: passing `optional = true` you create feature with name same as dependency. So with this code you've create 2 features with same name
<re_irc> <@n​ewam:m​atrix.org> burrbull: Yeah is there any way to avoid that so that I can use the 'defmt' name?
<re_irc> <@n​ewam:m​atrix.org> I tried renaming defmt, but that didn't work:
<re_irc> <@n​ewam:m​atrix.org> > That is, names of features take after the name of the dependency, not the package name, when renamed.
fabic has quit [Ping timeout: 252 seconds]
<re_irc> <@w​illeml:m​atrix.org> Why does the tick context give a different struct than what the usb_rx context gives?
<re_irc> <@w​illeml:m​atrix.org> ```rust
<re_irc> <@w​illeml:m​atrix.org> usb_dev.poll(&mut [usb_hid]);
<re_irc> <@w​illeml:m​atrix.org> }
<re_irc> <@w​illeml:m​atrix.org> fn usb_poll(usb_dev: &mut UsbDevice, usb_hid: &mut UsbHid) {
<re_irc> <@w​illeml:m​atrix.org> error:
<re_irc> <@w​illeml:m​atrix.org> --> src/main.rs:118:21
<re_irc> <@w​illeml:m​atrix.org> |
<re_irc> <@w​illeml:m​atrix.org> error[E0308]: mismatched types
<re_irc> <@h​enrik_alser:m​atrix.org> willeml: Looks like you’re using an old rtic version < 0.6? Then your type will be different depending on task priority, the lower prio task will have it wrapper in a Mutex
<re_irc> <@w​illeml:m​atrix.org> Ahh, ok, thanks
<re_irc> <@h​enrik_alser:m​atrix.org> So needs lock(|…..
<re_irc> <@w​illeml:m​atrix.org> I am using 0.5
<re_irc> <@w​illeml:m​atrix.org> I guess i will try to upgrade
<re_irc> <@h​enrik_alser:m​atrix.org> Can recommend! 0.6 syntax is so much nicer!
<re_irc> <@w​illeml:m​atrix.org> Ah yes, much nicer
<re_irc> <@h​enrik_alser:m​atrix.org> Here’s a basic USB mouse example with 0.6 https://github.com/kalkyl/f411-rtic/blob/main/src/bin/usb-mouse.rs
<re_irc> <@h​enrik_alser:m​atrix.org> There’s a lot of other basic 0.6 examples in there too of it helps you with the upgrade https://github.com/kalkyl/f411-rtic/tree/main/src/bin
<re_irc> <@w​illeml:m​atrix.org> Oh awesome, thanks, I am just trying to get basic HID working, (using mouse to test) then I want to eventually create firmware for custom joystick/throttle or something for hotas
<re_irc> <@h​enrik_alser:m​atrix.org> Last time i did a HID device there was an issue getting it to enumerate on windows (mac and linux works fine) turned out there was a missing field in the generated descriptors so had to code it by hand, i know perlindgren filed an issue but don’t know if it’s been fixed yet
<re_irc> <@w​illeml:m​atrix.org> macOS here, so probably fine
<re_irc> <@w​illeml:m​atrix.org> I keep getting Err(WouldBlock) whenever I try to send the HID report
cr1901 has quit [Read error: Connection reset by peer]
<re_irc> <@h​enrik_alser:m​atrix.org> Do you allow it some time to empty the buffer or do you just spam it continously? What’s your poll rate?
<re_irc> <@w​illeml:m​atrix.org> every 60ms I think
<re_irc> <@w​illeml:m​atrix.org> And I don't have any buffer (that I know of)
<re_irc> <@w​illeml:m​atrix.org> I know the example you sent uses on, but I cannot use one in the same way...
<re_irc> <@w​illeml:m​atrix.org> (usbbus struct new function does not take a buffer as an argument like in the example you linked)
<re_irc> <@h​enrik_alser:m​atrix.org> If you just spam it in the idle loop it won't allow it time to empty the usb endpoint memory in between your push_input calls
<re_irc> <@h​enrik_alser:m​atrix.org> So you could either do your push_input in the USB interrupt handler task instead or you need to put some delay in your idle loop
<re_irc> <@w​illeml:m​atrix.org> I have a `cortex_m::asm::delay(5_000_000)` in the idle loop
<re_irc> <@h​enrik_alser:m​atrix.org> (Maybe not a good idea to do your print inside the lock there btw, you want as short as possible critical section)
<re_irc> <@h​enrik_alser:m​atrix.org> Where do you poll?
<re_irc> <@h​enrik_alser:m​atrix.org> do the interrupts fire?
<re_irc> <@w​illeml:m​atrix.org> rx does
<re_irc> <@w​illeml:m​atrix.org> I don't see tx firing though
<re_irc> <@h​enrik_alser:m​atrix.org> what happens if you poll in the idle loop? like
<re_irc> <@h​enrik_alser:m​atrix.org> if !usb_dev.poll(&mut [usb_hid]) {
<re_irc> <@h​enrik_alser:m​atrix.org> continue;
<re_irc> <@h​enrik_alser:m​atrix.org> }
<re_irc> <@h​enrik_alser:m​atrix.org> What device are you using?
<re_irc> <@w​illeml:m​atrix.org> stm32f303disco
<re_irc> <@h​enrik_alser:m​atrix.org> I don't have one at hand right here so can't reproduce unfortunately
<re_irc> <@w​illeml:m​atrix.org> Hmm, so I started polling in the idle loop, now rx seems to stop firing after a second or two, and also, it no longer tries to push then input
<re_irc> <@w​illeml:m​atrix.org> Then, if I disable the tx and rx interupts I get that
<re_irc> <@w​illeml:m​atrix.org> And if I reduce the delay, it says success once and then says error once and then stops
<re_irc> <@w​illeml:m​atrix.org> (Note that throught this the mouse does not move and clicking the button does not seem to work)
<re_irc> <@d​irbaio:m​atrix.org> newam: Yes, with namespaced-features. Nightly only. Not possible in stable.
<re_irc> <@h​enrik_alser:m​atrix.org> willeml: btw usb doesn't have rx & tx interrupts, i think those names refer to the can interrupt, but HP/LP refers to the usb as "high/low priority"
<re_irc> <@h​enrik_alser:m​atrix.org> i think HP usually fires only for isochronous transfers
<re_irc> <@h​enrik_alser:m​atrix.org> and bulk complete iirc
<re_irc> <@h​enrik_alser:m​atrix.org> So i'd expect only LP to be used for interrupt transfers
<re_irc> <@h​enrik_alser:m​atrix.org> Hmm just checked the f303 interrupt enum and saw there's a USB_LP interrupt too? What happens if you use that one instead? And do the poll / push in that one?
<re_irc> <@w​illeml:m​atrix.org> both pull and push?
<re_irc> <@h​enrik_alser:m​atrix.org> Yes you can do this on top
<re_irc> <@h​enrik_alser:m​atrix.org> if !usb_dev.poll(&mut [usb_hid]) {
<re_irc> <@h​enrik_alser:m​atrix.org> and then push input below
<re_irc> <@h​enrik_alser:m​atrix.org> }
<re_irc> <@h​enrik_alser:m​atrix.org> return;
<re_irc> <@w​illeml:m​atrix.org> My probe is no longer workin...
<re_irc> <@h​enrik_alser:m​atrix.org> --connect-under-reset?
<re_irc> <@h​enrik_alser:m​atrix.org> Or `st-flash erase`
<re_irc> <@w​illeml:m​atrix.org> henrik_alser: This worked, thanks
<re_irc> <@w​illeml:m​atrix.org> henrik_alser: With those changes it no longer shows up as an HID device
<re_irc> <@w​illeml:m​atrix.org> I am going to go to sleep though, thanks for all the help!
<re_irc> <@h​enrik_alser:m​atrix.org> Ok, try the same for the interrupt that was working
<re_irc> <@h​enrik_alser:m​atrix.org> Sleep tight! :)
<re_irc> <@w​illeml:m​atrix.org> Thanks :)
<re_irc> <@s​tu_:m​atrix.org> Will the next meeting be on Thursday next week? We weren’t able to write up an issue with the new `cortex-a` crate design because I’m on vacation, but next week we’ll have something ready.
ni has quit [Quit: WeeChat 2.8]
ni has joined #rust-embedded
<re_irc> <@9​names:m​atrix.org> Thursday? The meetings usually happen on Tuesdays, 20:00 CEST
<re_irc> <@s​tu_:m​atrix.org> Ohh. Whoops. Thank you 😅
fabic has joined #rust-embedded
<re_irc> <@j​amesmunns:m​atrix.org> willeml: dumb question: you're running in release mode, right?
<re_irc> <@j​amesmunns:m​atrix.org> (USB tends to not work reliably/at all in unoptimized builds, I've found)
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
jackneill has joined #rust-embedded
jackneill has quit [Remote host closed the connection]
jackneill has joined #rust-embedded
jackneill has quit [Remote host closed the connection]
<re_irc> <@l​achlansneff:m​atrix.org> jamesmunns: Would be neat to be able to optimize just part of the build, like USB, while compiling the rest in debug. Is that possible?
<re_irc> <@j​amesmunns:m​atrix.org> Yup! look up "profile overrides"
<re_irc> <@j​amesmunns:m​atrix.org> you can change opt settings on a per-crate basis.
<re_irc> <@j​amesmunns:m​atrix.org> (exactly what you described is something I often do for debugging - keep all the deps optimized (or at least opt-level=1, which is still a big step), but leave the top level crate unoptimized, if I'm only debugging top level logic)
<re_irc> <@j​amesmunns:m​atrix.org> very handy for GDB work
<re_irc> <@j​amesmunns:m​atrix.org> But yeah, if you are doing certain things at the top level, like iterator loops, or deeply nested function calls that rely heavily on optimization to be zero cost, you can still end up with the final code being "too slow to work" though
<re_irc> <@d​irbaio:m​atrix.org> would this be UB?
<re_irc> <@d​irbaio:m​atrix.org> static LOCK_STATUS: AtomicU32 = AtomicU32::new(0);
<re_irc> <@d​irbaio:m​atrix.org> ```rust
<re_irc> <@d​irbaio:m​atrix.org> #[link_section = ".uninit"]
<re_irc> <@d​irbaio:m​atrix.org> goal is to have the value "persist" across warm reboots (where power to RAM isn't cut)
<re_irc> <@j​amesmunns:m​atrix.org> hm
<re_irc> <@j​amesmunns:m​atrix.org> I have no idea
<re_irc> <@d​irbaio:m​atrix.org> so if device reboots while unlocked, it can lock itself again
<re_irc> <@j​amesmunns:m​atrix.org> I feel like `MaybeUninit` would be the right answer here
<re_irc> <@j​amesmunns:m​atrix.org> but... it seems silly.
<re_irc> <@d​irbaio:m​atrix.org> hmm... even with MaybeUninit it'd be doing an "assume_init" right after boot though
<re_irc> <@j​amesmunns:m​atrix.org> yeah
<re_irc> <@c​hrysn:p​rivacytools.io> Not sure either (agreeing with both "would be the right answer" and "seems silly")
<re_irc> <@c​hrysn:p​rivacytools.io> From a UB perspective, mightn't it be best to define the area in the linker script as used only, and access it through an extern atomic pointer?
<re_irc> <@c​hrysn:p​rivacytools.io> That way, at no point in time can there be expectations in the Rust memory model about its contents.
<re_irc> <@d​irbaio:m​atrix.org> maybe yeah
<re_irc> <@j​amesmunns:m​atrix.org> yeah, that'll pretty much always work here, probably because of pointer escaping
<re_irc> <@d​irbaio:m​atrix.org> I don't relaly need atomics
<re_irc> <@d​irbaio:m​atrix.org> maybe volatile read/write seems safer..?
<re_irc> <@j​amesmunns:m​atrix.org> would definitely be more clearly correct
<re_irc> <@j​amesmunns:m​atrix.org> (but might be "overkill")
<re_irc> <@c​hrysn:p​rivacytools.io> If it's an extern thing and not expected to be changed, even regular dereferencing might suffice.
<re_irc> <@j​amesmunns:m​atrix.org> I'd probably stick with volatile
<re_irc> <@j​amesmunns:m​atrix.org> at an assembly level, it's just a load
<re_irc> <@j​amesmunns:m​atrix.org> so it's not like perf is different
<re_irc> <@j​amesmunns:m​atrix.org> (or a store)
<re_irc> <@d​irbaio:m​atrix.org> ```rust
<re_irc> <@d​irbaio:m​atrix.org> struct SendIt(UnsafeCell<u32>);
<re_irc> <@d​irbaio:m​atrix.org> #[repr(transparent)]
<re_irc> <@d​irbaio:m​atrix.org> unsafe impl Sync for SendIt {}
<re_irc> <@d​irbaio:m​atrix.org> yolo
<re_irc> <@d​irbaio:m​atrix.org> should be fine I guess? the volatile read/writes are reading the value inside the UnsafeCell so I'm not "mutating readonly statics"
<re_irc> <@d​irbaio:m​atrix.org> and volatile should prevent the compiler from optimizing like "hey you're reading from this var without having written before, so its value must be 0!!!"
<re_irc> <@d​irbaio:m​atrix.org> no idea whether the compiler can do that optimization? 🤷
<re_irc> <@j​amesmunns:m​atrix.org> (you might want to be more defensive about the value being potentially garbage, but the approach LGTM)
<re_irc> <@t​halesfragoso:m​atrix.org> dirbaio: It's still UB :/
<re_irc> <@j​amesmunns:m​atrix.org> I mean, just as UB as any MMIO interaction
<re_irc> <@d​irbaio:m​atrix.org> yeah I only want to lock if I know for sure it was unlocked
<re_irc> <@d​irbaio:m​atrix.org> if it was locked, or I don't know (like, batteries removed) then do nothing
<re_irc> <@t​halesfragoso:m​atrix.org> jamesmunns: Not really, MMIO is in fact inited
<re_irc> <@d​irbaio:m​atrix.org> because locking while already locked stresses the motor a bit :S
<re_irc> <@j​amesmunns:m​atrix.org> I mean, yeah, but not at the discretion of the software
<re_irc> <@t​halesfragoso:m​atrix.org> jamesmunns: But the software can't prove it's uninit, so if it assume it's then that is a compiler bug
<re_irc> <@j​amesmunns:m​atrix.org> yeah
<re_irc> <@t​halesfragoso:m​atrix.org> On this case the compiler can prove it
<re_irc> <@j​amesmunns:m​atrix.org> that's the pointer escaping sort of but
<re_irc> <@j​amesmunns:m​atrix.org> *bit
<re_irc> <@t​halesfragoso:m​atrix.org> I'm not saying it won't do the volatile read correct
<re_irc> <@d​irbaio:m​atrix.org> the only difference between this and MMIO is that here the compiler can see the pointer comes from a static
<re_irc> <@t​halesfragoso:m​atrix.org> I'm saying that's UB
<re_irc> <@j​amesmunns:m​atrix.org> Ah, because it's a static, rather than an arbitrary pointer?
<re_irc> <@j​amesmunns:m​atrix.org> so it WOULDN'T be pointer-escaped?
<re_irc> <@j​amesmunns:m​atrix.org> yeah, something like putting a linker u32 variable, and using the pointer to that linker variable instead of the static itself would probably be properly escaped
<re_irc> <@t​halesfragoso:m​atrix.org> My easy way to go that is: the thing is uninit ? If it's then the compiler can find a way to prove it
<re_irc> <@d​irbaio:m​atrix.org> jamesmunns: these linker variables are also statics though!
<re_irc> <@j​amesmunns:m​atrix.org> yeah
<re_irc> <@j​amesmunns:m​atrix.org> but they are SOMEBODY ELSE'S statics
<re_irc> <@j​amesmunns:m​atrix.org> not rustc's.
<re_irc> <@d​irbaio:m​atrix.org> oh because extern, hmm wtf
<re_irc> <@c​hrysn:p​rivacytools.io> jamesmunns: Yes, that's what I meant by defining it in the linker script
<re_irc> <@c​hrysn:p​rivacytools.io> Then they'd come from somewhere where the Rust compiler can't see. (It *can* see in the example that it's 0-init'ed).
<re_irc> <@d​irbaio:m​atrix.org> it'd be Great Shame that this can't be done without linker script hax :S
<re_irc> <@t​halesfragoso:m​atrix.org> dirbaio: Arent they just pointers for rustc ?
<re_irc> <@j​amesmunns:m​atrix.org> ```rust
<re_irc> <@j​amesmunns:m​atrix.org> extern "C" {
<re_irc> <@j​amesmunns:m​atrix.org> static mut LOCK_BITS: u32;
<re_irc> <@j​amesmunns:m​atrix.org> fn get_lock_val() -> u32 {
<re_irc> <@j​amesmunns:m​atrix.org> (maybe?)
<re_irc> <@j​amesmunns:m​atrix.org> (can you take a pointer without making a mut ref first?)
<re_irc> <@c​hrysn:p​rivacytools.io> jamesmunns: There's the *raw RFC, not sure that's done yet.
<re_irc> <@t​halesfragoso:m​atrix.org> dirbaio: Write its address to a random register and do a `compiler_fence` hahah
<re_irc> <@j​amesmunns:m​atrix.org> dirbaio: If you are playing within Rust's environment, you have to play by the rules :)
<re_irc> <@j​amesmunns:m​atrix.org> https://lab.jamesmunns.com/notes/2021/2021-03-23.html
<re_irc> <@9​names:m​atrix.org> or jump through asm/C?
<re_irc> <@j​amesmunns:m​atrix.org> But if you are crossing the environmental boundary, you may get the compiler to throw up it's hands
<re_irc> <@j​amesmunns:m​atrix.org> (in this case, using C/ASM/Linker script hacks all have the same effect: Crossing out of a "pure rust" environment)
<re_irc> <@9​names:m​atrix.org> okay, let me put this a different way. is there anyway to get the address of the variable, as an integer, without it being UB?
<re_irc> <@d​irbaio:m​atrix.org> why is it UB with volatile though?
<re_irc> <@d​irbaio:m​atrix.org> volatile is specified to "do a read to the given address no matter what"
<re_irc> <@j​amesmunns:m​atrix.org> you have a variable, "owned" by Rust, that is not fulfilling the contract
<re_irc> <@j​amesmunns:m​atrix.org> YOU SAID it was a static
<re_irc> <@j​amesmunns:m​atrix.org> which is initialized as part of the environmental contract
<re_irc> <@j​amesmunns:m​atrix.org> BUT, you put it in a linker script section that DOES NOT FULFILL that contract.
<re_irc> <@d​irbaio:m​atrix.org> so the read will produce *some* u32 value, and all bit patterns are valid u32's
<re_irc> <@t​halesfragoso:m​atrix.org> dirbaio: Something something LLVM undef, poison, something
<re_irc> <@j​amesmunns:m​atrix.org> therefore, you lied to the compiler, and it is allowed to do whatever the hell it feels like now
<re_irc> <@j​amesmunns:m​atrix.org> yeah
<re_irc> <@d​irbaio:m​atrix.org> 🤔
<re_irc> <@j​amesmunns:m​atrix.org> This is the barrier between "what the hardware does", and "the theoretical model the compiler holds"
<re_irc> <@t​halesfragoso:m​atrix.org> But tbh, I doubt it would do something different with volatile
<re_irc> <@j​amesmunns:m​atrix.org> JUST BECAUSE you think you know what a given line of Rust (or C, or C++) will do at a hardware level, the compiler is under no restriction to do exactly that.
<re_irc> <@j​amesmunns:m​atrix.org> but yeah
<re_irc> <@t​halesfragoso:m​atrix.org> But, you know, UB
<re_irc> <@j​amesmunns:m​atrix.org> this is "theoretical, not practical, UB"
<re_irc> <@j​amesmunns:m​atrix.org> your original code will probably work just fine :D
<re_irc> <@j​amesmunns:m​atrix.org> it's just not guaranteed.
<re_irc> <@t​halesfragoso:m​atrix.org> Tbh, now that you putted that on a specific part of the link script with label and stuff
<re_irc> <@t​halesfragoso:m​atrix.org> Maybe is not UB ? The compiler isn't sure something isn't initting them, right ?
<re_irc> <@c​hrysn:p​rivacytools.io> ... and any smart-ass compiler upgrade may break it, because there's some other case in which the theoretically allowed optimization makes sense.
<re_irc> <@j​amesmunns:m​atrix.org> (link script labels don't change the requirements)
<re_irc> <@t​halesfragoso:m​atrix.org> Or maybe the compiler just do that with normal statics
<re_irc> <@t​halesfragoso:m​atrix.org> I.e. consider them inited
<re_irc> <@j​amesmunns:m​atrix.org> ```rust
<re_irc> <@j​amesmunns:m​atrix.org> #[link_section = ".rodata"] // Read-only mapped memory
<re_irc> <@j​amesmunns:m​atrix.org> use core::sync::atomic::{AtomicUsize, Ordering};
<re_irc> <@j​amesmunns:m​atrix.org> static BAD: AtomicUsize = AtomicUsize::new(0);
<re_irc> <@9​names:m​atrix.org> the LLVM thing is about the pointer, not the access. it knows you got your pointer from another pointer.
<re_irc> <@9​names:m​atrix.org> you escape that by getting a pointer from an integer, which is why I asked if it's UB to get an integer address from a pointer (AFIAK it is not)
<re_irc> <@j​amesmunns:m​atrix.org> (this segfaults at runtime, but I've been reassured this is NOT UB, this is the user breaking the environmental contract)
<re_irc> <@9​names:m​atrix.org> the construction will always be unsafe, like all of our FFI
<re_irc> <@t​halesfragoso:m​atrix.org> I meant because the compiler assumes all statics (normal?) are initialized, even though it didn't initialized it itself
jackneill has joined #rust-embedded
<re_irc> <@t​halesfragoso:m​atrix.org> I.e. .bss .data
<re_irc> <@t​halesfragoso:m​atrix.org> 9names: Today you need to go through a reference, so the thing would need to be MaybeUninit
<re_irc> <@t​halesfragoso:m​atrix.org> Now Im on the fence if it's UB dirbaio haha
<re_irc> <@t​halesfragoso:m​atrix.org> Just because how .data and .bss statics work
<re_irc> <@n​ihal.pasham:m​atrix.org> just thought I'd check to see if this exists in the community. I'm working on a bootloader with update capabilities (which relies on A/B partitions) for ARM. I have the following questions
<re_irc> <@n​ihal.pasham:m​atrix.org> - do we have a way to stitch multiple binaries together? - like say `bootloader + boot firmware + update firmware` laid out in contiguous memory with predefined offsets.
<re_irc> <@n​ihal.pasham:m​atrix.org> - also, does `cargo flash` (i.e. probe-rs) support flashing such a blob?
<re_irc> <@n​ihal.pasham:m​atrix.org> my current plan is to manually work out of the offsets and flash with something like `pyocd.` I'd love to hear about a better way to do this.
<re_irc> <@a​damgreig:m​atrix.org> usually you'd make all three firmwares separate projects and flash them individually
<re_irc> <@a​damgreig:m​atrix.org> memory.x indicates the flash start address and can differ for each firmware, and probe-rs will just flash that one firmware
<re_irc> <@d​irbaio:m​atrix.org> you can do that with some post-build step: convert the elfs to hex and then mergehex
<re_irc> <@a​damgreig:m​atrix.org> each firmware needs to occupy separate flash memory banks to allow them to be reprogrammed separately
<re_irc> <@a​damgreig:m​atrix.org> but yea, in the situation where you do want to do a single probe-rs programming step to flash all three together (factory production?), you can merge three elfs to a single elf, or convert to binary and pad and 'cat', or mergehex, or whatever
<re_irc> <@a​damgreig:m​atrix.org> but honestly i'd just have three elfs and run cargo-flash three times
<re_irc> <@a​damgreig:m​atrix.org> shouldn't be any appreciable difference in flash time, and makes updating any one binary much easier too
<re_irc> <@d​irbaio:m​atrix.org> doing a single flash is faster because you can do chip-erase
<re_irc> <@a​damgreig:m​atrix.org> hmm
<re_irc> <@a​damgreig:m​atrix.org> whether that's faster depends on how many sectors you need, right?
<re_irc> <@a​damgreig:m​atrix.org> if you're using most of the flash I guess it probably would be though
<re_irc> <@d​irbaio:m​atrix.org> depends on the chip ofc
<re_irc> <@d​irbaio:m​atrix.org> on nrf's it's maaaasssively faster
<re_irc> <@a​damgreig:m​atrix.org> faster than e.g. only erasing one sector?
<re_irc> <@a​damgreig:m​atrix.org> or, say, three sectors
<re_irc> <@a​damgreig:m​atrix.org> anyway yea it's a good point, maybe for that production programming you do want a script that takes the three elfs and combines them then runs cargo-flash once with chip-erase
<re_irc> <@d​irbaio:m​atrix.org> on nrf52840:
<re_irc> <@d​irbaio:m​atrix.org> erase page: 85ms
<re_irc> <@d​irbaio:m​atrix.org> erase all: 169ms
<re_irc> <@c​hrysn:p​rivacytools.io> Separate flashes can still be fast if there is a full-chip erase before -- provided the flasher checks for whether a page-wise erase is actually necessary
<re_irc> <@n​ihal.pasham:m​atrix.org> I'm more worried about someone forgetting to flash one of them (and raising tickets without checking). Yep, binary padding and merging is what we have then.
<re_irc> <@d​irbaio:m​atrix.org> you don't need to merge files to get fast chip-erase flashes though
<re_irc> <@d​irbaio:m​atrix.org> both probe-rs and pyocd allow you to create a "loader", load multiple elfs, then flash all in one go with a single chip-erase
<re_irc> <@a​damgreig:m​atrix.org> another option is to flash only the bootloader and then use it to program the rest of the chip
<re_irc> <@a​damgreig:m​atrix.org> can be quicker since e.g. ethernet or HS USB can do way higher data rates than you're likely getting with SWD
<re_irc> <@a​damgreig:m​atrix.org> (and verifies bootloader functionality while you're at it)
<re_irc> <@d​irbaio:m​atrix.org> yeah but the flash writing itself will probably be slower...?
<re_irc> <@d​irbaio:m​atrix.org> because the bootloader will have to do sector-erases, it can't do a chip-erase
<re_irc> <@a​damgreig:m​atrix.org> I guess it depends on chip and setup, no reason the bootloader couldn't be told that a chip erase had already taken place or perhaps check itself
<re_irc> <@a​damgreig:m​atrix.org> on some chips the flash is two banks and you can do bank-erase on each, too
<re_irc> <@d​irbaio:m​atrix.org> right :P
<re_irc> <@n​ihal.pasham:m​atrix.org> adamgreig: this one's a secure bootloader with a focus on the smallest possible TCB. So, no networking stacks of any kind. we'll rely on the firmware for that
<re_irc> <@a​damgreig:m​atrix.org> for sure getting into the weeds here though :P
<re_irc> <@n​ihal.pasham:m​atrix.org> but great, thanks for the confirmation
<re_irc> <@a​damgreig:m​atrix.org> right fair enough, then yea I guess either merge your three ELFs to a single ELF/hex/bin, or use probe-rs's API to load the three ELFs separately (in a production environment)
<re_irc> <@a​damgreig:m​atrix.org> I wonder if cargo-flash couldn't just support being given multiple --elf arguments
<re_irc> <@a​damgreig:m​atrix.org> seems like an easy feature addition
<re_irc> <@d​irbaio:m​atrix.org> yup!
<re_irc> <@d​irbaio:m​atrix.org> though if you're doing factory programming you'll want extra custom logic anyway
<re_irc> <@n​ihal.pasham:m​atrix.org> +1 to that
<re_irc> <@d​irbaio:m​atrix.org> like provisioning keys or unique serial numbers or running tests
<re_irc> <@d​irbaio:m​atrix.org> at that point you might as well use probe-rs as a lib, instead of execing cargo-flash
<re_irc> <@a​damgreig:m​atrix.org> yea
<re_irc> <@a​damgreig:m​atrix.org> I'm inferring this is more for people who are programming their own device if you're worried about them missing one or two of the images
<re_irc> <@d​irbaio:m​atrix.org> I have my main app purposefully suicide if the bootloader is not there :D
<re_irc> <@9​names:m​atrix.org> how does your main app execute if the bootloader is missing?
<re_irc> <@d​irbaio:m​atrix.org> due to the weird-ass flash layout of the softdevice
<re_irc> <@9​names:m​atrix.org> oh right nrf stuff forget i asked :D
<re_irc> <@d​irbaio:m​atrix.org> bootloader goes at the *end* of flash
<re_irc> <@d​irbaio:m​atrix.org> the softdevice will boot the main app if no bootloader is flashed
<re_irc> <@d​irbaio:m​atrix.org> so it's super easy to miss :S
<re_irc> <@d​irbaio:m​atrix.org> true that in a more conventional layout where the BL goes at the start of flash this can't happen
<re_irc> <@d​irbaio:m​atrix.org> damn you nordic
<re_irc> <@y​atekii:m​atrix.org> dirbaio: see, I need to create my service already :D
jackneill has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
<re_irc> <@w​illeml:m​atrix.org> jamesmunns: Actually, I am not, I will try it
troth has joined #rust-embedded
<re_irc> <@j​amesmunns:m​atrix.org> willeml: How'd it go?
fabic has quit [Ping timeout: 248 seconds]
<re_irc> <@j​amesmunns:m​atrix.org> Anyone know someone who knows someone who works at Raspberry Pi? I'm back on my "convince vendors to have official rust support" bullshit: https://twitter.com/bitshiftmask/status/1426254350125568002
<re_irc> <@j​amesmunns:m​atrix.org> (I have been reinvigorated by espressif's recent hires :D )
<re_irc> <@a​damgreig:m​atrix.org> hires plural?
<re_irc> <@a​damgreig:m​atrix.org> probably #rp-rs:matrix.org is the place to discuss, and I think at least one or two relevant people are there too
<re_irc> <@j​amesmunns:m​atrix.org> That's fair!
<re_irc> <@j​amesmunns:m​atrix.org> adamgreig: I think there were two, Scott and someone else, unless I have wires crossed with Tweedegolf hiring Dion (which also happened recently)
<re_irc> <@a​damgreig:m​atrix.org> (though I think they hang out there in an unofficial capacity :P)
<re_irc> <@a​damgreig:m​atrix.org> cool! i was just aware of scott
xnor has quit [Ping timeout: 268 seconds]
xnor has joined #rust-embedded
GenTooMan has quit [Ping timeout: 245 seconds]
GenTooMan has joined #rust-embedded
xnor has quit [Changing host]
xnor has joined #rust-embedded
<re_irc> <@w​illeml:m​atrix.org> jamesmunns: It didn’t work sadly, still says err would block
<re_irc> <@j​atsekku:m​atrix.org> I can't get oled working properly, any ideas?
<re_irc> <@j​atsekku:m​atrix.org> its based on examples in ssd1306 crate
GenTooMan has quit [Ping timeout: 245 seconds]
GenTooMan has joined #rust-embedded
<re_irc> <@a​lmindor:m​atrix.org> how can we add a risc-v member to the https://github.com/riscv-rust organization so they can review etc ?
<re_irc> <@a​lmindor:m​atrix.org> any of the owners still around? :D
<re_irc> <@j​amesmunns:m​atrix.org> CC disasm
<re_irc> <@j​amesmunns:m​atrix.org> Might also want to ask around in #gd32v-rust:matrix.org almindor
<re_irc> <@j​amesmunns:m​atrix.org> I know most of the RISC V folks hang out there too
<re_irc> <@j​amesmunns:m​atrix.org> Ah, see you're already there :D
<re_irc> <@a​lmindor:m​atrix.org> will do, we should get dkhayes117 at least the collaborator role so he can review
<re_irc> <@o​ddstr13:m​atrix.org> jatsekku: looks working to me, except for bitmap size
GenTooMan has quit [Ping timeout: 256 seconds]
GenTooMan has joined #rust-embedded