09:11 <lulf[m]> <dirbaio[m]> "I wanted to do something like..." <- I was thinking maybe a way would be to create a FuzzFlash which could be created with write, read, erase and corruption rates. Upon performing the operation, it draws a random number and returns error or (in the case of writes) corrupts the data silently. Then one can just run this with different parameters many iterations. Logging all operations to reproduce a test error would be nice

09:11 <lulf[m]> too. Could be useful for anything working with embedded-storage traits

09:15 <lulf[m]> * a FuzzFlash implementing embedded-storage, which could

09:22 <andresovela[m]> How can I generate documentation for a binary crate? I tried the --document-private-items option but it still doesn't generate anything other than exit for my main crate

09:22 <andresovela[m]> My project is based off the knurling template, so it has a main.rs and a lib.rs

09:22 <andresovela[m]> It seems only lib.rs is being documented

09:24 <andresovela[m]> * How can I generate documentation for a binary crate? I tried the --document-private-items option but it still doesn't generate anything other than exit and panic for my main crate

11:24 <JamesMunns[m]> It's the difference between the lib and bin crate andresovela

11:24 <JamesMunns[m]> You might be able to pass cargo doc --bin or something like that?

11:25 <JamesMunns[m]> The knurling template actually gives you a structure that has two "crates" (sort of), the lib crate in lib-rs, and the bin crate of your application (main-rs or bin/whatever-rs)

11:42 <lulf[m]> * I was thinking maybe a way would be to create a FailFlash implementing embedded-storage, which could be created with write, read, erase and corruption rates. Upon performing the operation, it draws a random number and returns error or (in the case of writes) corrupts the data silently. Then one can just run this with different parameters many iterations. Logging all operations to reproduce a test error would be nice too. Could be

11:42 <lulf[m]> useful for anything working with embedded-storage traits

12:43 <lkostka[m]> What's your experience ?

12:43 <lkostka[m]> Hi. I am beginner in rust embedded. I am familiar with C, C++ embedded. I know how to optimise code, read assembly etc in C, C++. I wonder however how rust (with borrow checker) will emit fairly optimised code. My most concern is about interrupt handlers and global (static in rust case) variables like buffers.

12:43 <diondokter[m]> lkostka[m]: > <@lkostka:matrix.org> Hi. I am beginner in rust embedded. I am familiar with C, C++ embedded. I know how to optimise code, read assembly etc in C, C++. I wonder however how rust (with borrow checker) will emit fairly optimised code. My most concern is about interrupt handlers and global (static in rust case) variables like buffers.

12:43 <diondokter[m]> > What's your experience ?

12:43 <diondokter[m]> The borrow checker only exists at compile time. Your code can/will be just as close to the metal as C

12:46 <lkostka[m]> I think that I will use https://crates.io/crates/stm32f1 crate since it provides all registers and I will build higher abstractions myself. Only problem is that all of them are singletons. I do solve this problems in C++ with using/typedefs and a function that accepts it.

12:51 <d3zd3z[m]> <Mathias[m]> "d3zd3z: There is a way to read..." <- You're right, this does look like it verifies that the ECC is correct. It's kind of unfortunate that the ROM driver doesn't seem to support this, but at least the hardware does, and this looks easier to deal with than trying to recover from the fault.

13:06 <lkostka[m]> BTW how do you do conditional compilation. For example when you have multiple boards, one has 2 stepper drivers, second has 4, and for a twist they differ in MCU vendor ?

13:08 <K900> #[cfg] attributes

13:08 <diondokter[m]> lkostka[m]: For straightforward conditional compilation we have `cfg` and crate features: https://doc.rust-lang.org/reference/conditional-compilation.html

13:08 <diondokter[m]> With the change in PAC. we typically do that through the typesystem using traits

13:08 <diondokter[m]> s/we/We/

13:08 <diondokter[m]> Or macros I guess

13:10 <mameluc[m]> you can do a lot with features and hals but it also depends also on how much code is the same between the boards, sometimes it is just easier to have two projects and put the common code in another crate

13:13 <mameluc[m]> this is probably the fifth time I paste this and there is probably newer resources but this project helped me think about my project

13:13 <mameluc[m]> https://github.com/titanclass/embassy-start/tree/master/client/embedded-app/src

13:47 <waveguide[m]> <lkostka[m]> "Hi. I am beginner in rust..." <- > <@lkostka:matrix.org> Hi. I am beginner in rust embedded. I am familiar with C, C++ embedded. I know how to optimise code, read assembly etc in C, C++. I wonder however how rust (with borrow checker) will emit fairly optimised code. My most concern is about interrupt handlers and global (static in rust case) variables like buffers.

13:47 <waveguide[m]> You can have global mutable statics, but access will need to be wrapped in unsafe and that’s just fine

13:47 <waveguide[m]> > What's your experience ?

13:59 <Lumpio[m]> <lkostka[m]> "Hi. I am beginner in rust..." <- > <@lkostka:matrix.org> Hi. I am beginner in rust embedded. I am familiar with C, C++ embedded. I know how to optimise code, read assembly etc in C, C++. I wonder however how rust (with borrow checker) will emit fairly optimised code. My most concern is about interrupt handlers and global (static in rust case) variables like buffers.

13:59 <Lumpio[m]> > What's your experience ?

13:59 <Lumpio[m]> The borrow checker is entirely a compile time thing. I don't think it would be a cause of emitting less optimal code in and of itself. Rust's reference rules even allow optimizations that are not commonly done in C (like assuming there is no pointer aliasing - although I still don't remember whether that works yet or was it reverted again because it broke things.

13:59 <Lumpio[m]> However it is possible that you might need to use runtime stuff (like RefCell for example) to implement things the borrow checker cannot support in safe rust.

13:59 <JamesMunns[m]> Lumpio[m]: I think it's back now! It did go back and forth a few times over a few years.

13:59 <Lumpio[m]> s//`/, s//`/, s/./, while in C you wouldn't need that if you're sure you know what you're doing™./

14:00 <FlixtheNewbie[m]> Yeah, it was a bit like reading a novel with a lot of episodes

14:25 <StephenD[m]> Question, but how are firmware updates normally implemented? At a high level I understand how they work but I'm curious if there are any crates or anything that makes it easier. I'm using rtic on an stm32

14:25 <StephenD[m]> Ideally I'd like to update the firmware using the normal usb_fs thing

14:25 <JamesMunns[m]> So, there's usually two ways (specific to usb+stm32):

14:26 <JamesMunns[m]> most stm32 devices have a "hardware bootloader" that can do DFU updates, meaning you don't have to write a bootloader

14:26 <JamesMunns[m]> Usually these are triggered by holding a GPIO low on reset, and then the hw bootloader takes over, and you can use standard tools to update the firmware

14:27 <JamesMunns[m]> the other way would be to write your own, which is usually only needed when you want some custom behavior like checking that the update is signed, or some kind of fail-safe mode, or work over some other interface like a radio or something

14:27 <firefrommoonligh> I let teh user download a standalone exectuable that does it

14:28 <firefrommoonligh> Per release

14:28 <firefrommoonligh> Run executable. It directs user to press the boot button while applying power and press a key when ready. Flashing happens

14:28 <StephenD[m]> firefrommoonligh: What we're talking about is what that executable would do - ie, how would it communicate with the stm32 - as well as how the stm32 would take in that data and apply it to flash

14:28 <firefrommoonligh> Probably will integrate it into the PC GUI software used to configure and check status as well

14:29 <firefrommoonligh> Oh

14:29 <firefrommoonligh> Wraps DFU-util

14:29 <firefrommoonligh> How the stm32 does it is magic (Something lower level than I work with)

14:29 <StephenD[m]> JamesMunns[m]: This is good to know. Does that communicate over the usb pins then?

14:29 <firefrommoonligh> Yes

14:29 <StephenD[m]> Awesome

14:29 <firefrommoonligh> I'm also trying to get a CAN bootloader set up for updates over CAN, but no luck there yet

14:29 <StephenD[m]> I'll look into DFU then, thanks

14:30 <firefrommoonligh> Btw, this is using the first process James already described

14:30 <JamesMunns[m]> StephenD[m]: Yup! I think it's also possible to "jump to bootloader" from the app as well, so you don't need to hold a GPIO. I've done it on some chips, but it wasn't super reliable always, but I could have been holding it wrong

14:30 <firefrommoonligh> And the CAN loader is the second wday James described

14:31 <firefrommoonligh> JamesMunns[m]: I think you need a custom bootloader for this; 99% sure it's possible, but I haven't done it

14:31 <JamesMunns[m]> there's an STM32 app note that has the hardware bootloader address in ROM and RAM for all the different families, which should be enough to allow you to "jump to bootloader" if you get the command in the app

14:31 <JamesMunns[m]> firefrommoonligh: Disagree! I've done this on stm32f0 and f4, iirc.

14:31 <firefrommoonligh> Really!

14:31 <JamesMunns[m]> well, "disagree you need a custom bootloader"

14:32 <JamesMunns[m]> yeah, for a while I had my panic impl just jump to the bootloader lol

14:32 <firefrommoonligh> Hmm. I should probalby try; would be useful and wouldn't need to expose the boot button on enclosures...

14:32 <JamesMunns[m]> "oh we panicked? time for a new firmware!"

14:32 <firefrommoonligh> V cool

14:33 <StephenD[m]> JamesMunns[m]: Oh nice. Just with a jmp instruction then?

14:33 <firefrommoonligh> James - is there an easy way to implement this?

14:33 <JamesMunns[m]> old code: https://github.com/jamesmunns/OtterPill-rs/blob/13d7de4fed90fbb4f7d936f76358d0465aea7b15/vintage/src/main.rs#L231-L239

14:33 <firefrommoonligh> Would you still wrap dfu-util, or some other way?

14:34 <JamesMunns[m]> today I'd probably use the cortex_m::asm::bootload function which does the msp + pc setting in one shot

14:34 <JamesMunns[m]> I think the issue I was having before is you probably also need to set the vtor through scb to do it. Note that those SP and PC constants vary by chip! You gotta find that app note.

14:35 <firefrommoonligh> I should prob switch to something like that

14:35 <JamesMunns[m]> firefrommoonligh: I was just using dfu-util with cargo-make at the time, iirc. cargo build to make the elf, objcopy to make a bin, pass to dfu-util to do the update

14:36 <StephenD[m]> I think actually I'll go the hardware route, so if the firmware update fails it doesn't brick the device. I'm working on hardware that I want to sell to ham radio operators so it's consumer-ish

14:36 <JamesMunns[m]> the f0 worked reliably, the f4 would sometimes get a little glitchy after a couple bootloads - like I said I THINK that was just not setting the VTOR, but I could be wrong.

14:36 <firefrommoonligh> So, I generally ship the devices with a UI program that interacts over USB/serial. It lets you do various config and checking everything's good etc. I've been doing the firmware updates as separate executables. Maybe when I integrate, I can skip the Boot0/DFU process like James does. Seems like saves a step and mildly simplifies enclosure design

14:36 <firefrommoonligh> I don't know what the risks are for the approach James uses, but the boot0 is, as far as I can tell, not possible to brick

14:36 <firefrommoonligh> (The only way I've managed to brick stm32s is by overvolting)

14:37 <JamesMunns[m]> yeah, you can't really brick the hw bootloader

14:37 <JamesMunns[m]> which is a nice benefit. even if an upload fails, if you do have the access to the boot0 pin (even if inconvenient), you're pretty much good to go.

14:38 <JamesMunns[m]> yeah, unless I had some kind of security or other reason (like requiring signed updates or something), I'd probably just use DFU + the hw bootloader on stm32 10/10 times

14:38 <StephenD[m]> JamesMunns[m]: Ah, so that's what the boot0 pin does. I assumed I could load two different programs onto flash and the boot0 would just set the initial pc

14:38 <JamesMunns[m]> StephenD[m]: uh, I think on some chips there is something vaguely like this? or it changes the flash mapping? depends on the chip

14:39 <StephenD[m]> I'm using an stm32f411 dev board with a boot0 pin

14:39 <JamesMunns[m]> I think on most newer chips there's only "force bootloader boot" on those pins, older ones had boot0 and boot1 which I don't remember all the permutations of

14:39 <firefrommoonligh> Btw, a lazy option is to offer the .bin file as a download, and direct the user to use Boot0 with STM32-cube-programmer, but IMO it's not user friendly and the download for that alone is bloaty

14:39 <JamesMunns[m]> (f411 is relatively "older" tho, so boot0/1 stuff may apply, read your reference manual to find out more 😅)

14:40 <firefrommoonligh> It's sometimes surprising which parts of STM32 hardwares are conserved among the various generations and which aren't

14:40 <JamesMunns[m]> firefrommoonligh: Always a "fun" read: https://docs.google.com/spreadsheets/d/1-R-AjYrMLL2_623G-AFN2A9THMf8FFMpFD4Kq-owPmI/edit?usp=sharing

14:41 <firefrommoonligh> Yea god bless dirbaio

14:41 <firefrommoonligh> I have that bookmarked and check it from time to time

14:41 <FlixtheNewbie[m]> <JamesMunns[m]> "yeah, for a while I had my panic..." <- That's a good idea actually. I'm gonna do that

14:42 <JamesMunns[m]> FlixtheNewbie[m]: Yeah, I only did that during development, but it was pretty conceptually funny to me

14:42 <firefrommoonligh> I hate how I'm so reliant on one line of MCUs, but the series as a whole is so flexible, and so much code and PCB design considerations are conserved

14:42 <StephenD[m]> `Bus 001 Device 007: ID 0483:df11 STMicroelectronics STM Device in DFU Mode`

14:42 <StephenD[m]> sick, it worked

14:42 <firefrommoonligh> Is that DFU-util?

14:42 <FlixtheNewbie[m]> JamesMunns[m]: It's not my job, it's for something I use daily, so its' the right context for me to do that

14:43 <JamesMunns[m]> that looks like lsusb

15:51 <d3zd3z[m]> It seems that with the lpc55-hal, if I chain-load to another app, and it tries to set the clocks, the pll programming just locks up.

15:52 <d3zd3z[m]> I guess I do need to look more into the crate.

15:53 <d3zd3z[m]> I'm guessing that the code isn't correctly moving the CPU clock away from the pll before trying to program it.

15:57 <JamesMunns[m]> Some HALs may just assume that clocks and such are in a default state when configuring, which may not be true for chain loading. I recently solved this by having the bootloader:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ikPZKonGYjsZIWAqfzKsyvRb>)

15:58 <jessebraham[m]> "contains no tokens or contains more than one token" ???

16:31 <burrbull[m]> how patch looks like? and which registers do you try to collect?

16:32 <burrbull[m]> `T?CONFIG:`

16:36 <jessebraham[m]> I had tired T*CONFIG and T%sCONFIG, both of which work for the other devices' SVDs

16:36 <jessebraham[m]> It's just this one that for some reason won't collect

16:37 <jessebraham[m]> And I don't see any differences that would cause this in the SVD, and the error messages gives me zero clues 😅

16:38 <jessebraham[m]> I will take a break and take another look though, I guess

16:50 <burrbull[m]> `"T%sCONFIG": {}` -> `"T?CONFIG: {}"`. This is glob-like pattern to find registers you want to collect.

16:50 <burrbull[m]> * `"T%sCONFIG": {}` -> `"T?CONFIG": {}`. This is glob-like pattern to find registers you want to collect.

16:53 <burrbull[m]> If you want to specify array name manually:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/pFAckJPVDjWvlRYuSvUDVTGK>)

16:54 <burrbull[m]> * `"T%sCONFIG": {}` -> `"T?CONFIG": {}`. This is glob-like pattern to find registers you want to collect. It automatically replaces common part with "%s"

17:23 <burrbull[m]> * `"T%sCONFIG": {}` -> `"T?CONFIG": {}` or `"T*CONFIG": {}`. This is glob-like pattern to find registers you want to collect. It automatically replaces common part with "%s"

17:33 <jessebraham[m]> T%sCONFIG, T*CONFIG, and T?CONFIG all have the same behaviour. I've just hacked around this using _modify/_delete instead of _array for these registers, for now.

17:35 <burrbull[m]> what error with *. It should be different

17:40 <jessebraham[m]> It's the same lol

17:40 <jessebraham[m]> It's fine I've moved on for now, couldn't figure out why it worked for 2 chips but not the others 🤷

17:50 <burrbull[m]> possibly it is due to https://github.com/rust-embedded/svdtools/pull/166. Could you try svdtools 0.3.3, please?

18:55 <jessebraham[m]> Will probably have to wait until tomorrow but I can give it a shot

19:54 <ChaeyoungLee[m]> Hi! I'm new to this channel. Has anyone worked with Rust on STM32U5 series before?

20:14 <dirbaio[m]> yes, embassy-stm32 has quite complete support for it

20:16 <ChaeyoungLee[m]> yeah it seems like there's no stm32-rs support :/

20:29 <M9names[m]> embassy-stm32 is pretty good, why not give it a try?

20:30 <ChaeyoungLee[m]> i got it set up! i'm just familiar with stm32-rs

20:32 <ChaeyoungLee[m]> 'm playing with the examples script rn, [blinky.rs](https://github.com/embassy-rs/embassy/blob/main/examples/stm32u5/src/bin/blinky.rs) specifically. I changed the LED pin from `p.PH7` to `p.PH6` and the code won't get loaded. Any idea why it's not working? Both PH6 and 7 should be LEDs on the stm32u5 eval board.

20:32 <ChaeyoungLee[m]> * I'm playing

20:33 <dirbaio[m]> did you change the chip in both Cargo.toml and .cargo/config.toml ?

20:34 <ChaeyoungLee[m]> Cargo.toml yes, .cargo/config not really since I'm using GDB instead of probe-rs

20:37 <dirbaio[m]> and it works with PH7 and not PH6?

20:37 <ChaeyoungLee[m]> Actually just fixed it, the problem was with the memory.x

20:37 <ChaeyoungLee[m]> Both LEDs are getting lit up, sorry about that

20:37 <dirbaio[m]> ahh nice

20:38 <ChaeyoungLee[m]> embassy-stm generates a memory.x for the board right

20:38 <dirbaio[m]> yes

20:38 <dirbaio[m]> but you can provide your own too

20:39 <ChaeyoungLee[m]> yeah I was using mine and didn't specify the region for OTP

20:40 <ChaeyoungLee[m]> Perfect, thanks for the help!

22:30 <dirbaio[m]> korken89: https://github.com/embassy-rs/cortex25519

22:31 <dirbaio[m]> it's in worse shape than what I remembered, it uses curve25519-dalek for quite a bit of stuff that's not the core

22:33 <dirbaio[m]> in particular, standard ed25519 requires sha512, which means it uses Scalar::from_bytes_mod_order_wide() which is a bit nontrivial and could be optimized using the fe25519 asm