07:07 <BenPyeHeThey[m]> Have there been any efforts to make panic more suitable for small embedded targets? Panic strings are basically all of my .rodata. It would be nice if I could put the panic strings in a different section - which could be stripped out of the flash image. On a panic I would log the address of the string, filename, etc. You'd lose useful format strings but at least for me that's not disastrous...

07:07 <BenPyeHeThey[m]> * been any recent efforts to

07:07 <BenPyeHeThey[m]> * Have there been any recent efforts to make panic more suitable for small embedded targets? Panic strings make up most of my .rodata. It would be nice if I could put the panic strings in a different section - which could be stripped out of the flash image. On a panic I would log the address of the string, filename, etc. You'd lose useful format strings but at least for me that's not disastrous...

07:08 <BenPyeHeThey[m]> I know we can set panic to immediate abort - which does eliminate the panic strings, but then all I can hope to capture is the current register state and then use symbols/dissassembly to see what happened.

07:21 <TeXitoi[m]> <BenPyeHeThey[m]> "I know we can set panic to..." <- https://crates.io/crates/panic-probe with print-defmt? The strings will not be in the firmware.

07:24 <BenPyeHeThey[m]> I don't think that's true..? https://github.com/knurling-rs/defmt/blob/06650b9cad2e5c8ce35b5694e1b74b15d7ecf4b9/firmware/panic-probe/src/lib.rs#L14 And looking at `Display2Format` it does look like they are doing formatting on device, which is what I want to avoid

07:26 <burrbull[m]> the main feature of defmt is formatting on host

07:27 <Shellhound> right, but the format string here is {} and it's passed a string as a formatting argument?

07:28 <BenPyeHeThey[m]> Right, and the string arg is coming from `Display2Format` which specifically has a note that it uses `core::fmt` on device - https://github.com/knurling-rs/defmt/blob/06650b9cad2e5c8ce35b5694e1b74b15d7ecf4b9/defmt/src/impls/adapter.rs#L41C7-L41C7

07:34 <burrbull[m]> Read attentively . It says to use defmt::Format where possible instead of Display as it does not use core::fmt.

07:36 <BenPyeHeThey[m]> Sure - which is great when you control it, but whilst for the code you're writing you might be able to use defmt::Format or their panic macro, the crates you depend on, unwind etc are going to use the standard assert/panic macros which will be core::fmt

07:42 <Shellhound> "This adapter disables compression and uses the `core::fmt` code on-device!", and this adapter is used by panic-probe. panic-probe also says "note that defmt will not be used to efficiently format the message". all good hints that the panic string is formatted on-device.

11:34 <korken89[m]> We've discussed it before but I must say it again, ChaCha20Poly1305 is ❤️! How can it be almost 10x faster than the HW accelerated AES in nRF52 I'll never know xD

11:34 <korken89[m]> * We've discussed it before but I must say it again, ChaCha20Poly1305 is ❤️! How can it be almost 10x faster in SW than the HW accelerated AES in nRF52 I'll never know xD

11:35 <korken89[m]> I know James Munns did a lot of testing on this, do you happen to have saved your result/conclusions somewhere that's public? :)

11:38 <JamesMunns[m]> phew, it's on twitter somewhere

11:38 <korken89[m]> starts digging twitter

11:39 <JamesMunns[m]> https://twitter.com/bitshiftmask/status/1266896490796122113

11:42 <JamesMunns[m]> looks like a baseline of 80us or so for enc/dec, plus 750ns/byte or so? totally unscientific. But reasonably fast

11:42 <korken89[m]> ❤️

11:42 <JamesMunns[m]> that's chacha8, chacha20 will be a bit slower, but chacha rounds are fast AF, it's just some fixed point shifts and muls IIRC

11:43 <korken89[m]> It's fun that generating the nonce from HW RNG goes slower than encryption

11:44 <korken89[m]> Thank lord for the chacha_rng crate though :)

11:45 <JamesMunns[m]> Yeah, for most of my stuff I use chacha8rng for anything not actually secure

11:46 <korken89[m]> Oh, isn't it supposed to be cryptographically secure?

11:46 <korken89[m]> I mean, seed it every now and again with HW rng

11:46 <JamesMunns[m]> according to the "too much crypto" paper, chacha8 SHOULD be secure

11:47 <korken89[m]> Ah right, I was thinking about chacha20

11:48 <korken89[m]> Anyways, now to encrypt my keyboard's communication! :D

11:49 <JamesMunns[m]> not a cryptographer, etc etc lol

11:50 <korken89[m]> Haha

11:50 <korken89[m]> I see random bytes, eh looks secure

11:50 <JamesMunns[m]> I mean I do "pretty led patterns" more often than I do "secure comms"

11:50 <JamesMunns[m]> so chacha8 works great lol

11:51 <JamesMunns[m]> I use it a lot on stm32g0 with no hwrng, so I usually poll the internal temperature adc a bunch to generate initial entropy, then seed the chacha8 and use that

11:52 <korken89[m]> Nice!

11:52 <korken89[m]> I mean, if it's not for encryption and entropy will give you random enough

11:52 <korken89[m]> s/and/any/

11:53 <korken89[m]> Take the least significant bit of the temperature ADC 256 times :D

11:55 <JamesMunns[m]> yeah, I do basically that, though I do some fancy checks to make sure you don't have long runs of 0s/1s. tbh tho what I should do is just start a chacha8 hash with a fixed initial value, then hash the full reading of the ADC N times, maybe making sure the value isn't stuck (which shouldn't be true for the internal temp adc), then dump the calculated hash (or internal state of the hasher), and use that as a seed

11:56 <JamesMunns[m]> it's true the lowest bit SHOULD have the highest entropy, but there's no harm in including the higher bits even if they are relatively "fixed"

11:58 <korken89[m]> Yeah :)

11:58 <korken89[m]> I've never played with that tbh, always used the HW rng for seeding

11:58 <korken89[m]> But I always use it for crypto stuff too soooooo

11:58 <JamesMunns[m]> yeah, same on nrf, not on stm32g0 th

11:59 <JamesMunns[m]> s/th/tho/

11:59 <korken89[m]> Right right, now hw rng

11:59 <korken89[m]> s/now/no/

11:59 <korken89[m]> I wonder if I can find a blog on why the HW AES in the nRF52 is so slow

12:00 <korken89[m]> Or if I'm holding it wrong :P

12:03 <JamesMunns[m]> I think dirbaio has looked at it a lot. IIRC, AES-ECB (or -GCM? I can't remember what the hw does) is just more expensive by a lot than chacha20poly1305

13:15 <dirbaio[m]> <korken89[m]> "I wonder if I can find a blog on..." <- are you using the cc310, or the nordic-specific ECB peripheral?

13:17 <dirbaio[m]> ECB says it can do a 16b block in 7.2us, so 461 cycles

13:18 <dirbaio[m]> which is quite faster than the numbers in James Munns 's tweet (though that's chacha20poly1305, while the equivalent for raw aes would be just chacha20)

13:18 <dirbaio[m]> hmm

13:19 <dirbaio[m]> <TeXitoi[m]> "https://crates.io/crates/panic-..."; <- print-defmt *does* put the strings in the firmware

13:40 <yruama_lairba[m]> hi, i have heard about chiptool as an alternative to svd2rust. It seems it change drastically some philosophy how you implement and use HAL, is there some tutorial or something else to start with ?

13:47 <yruama_lairba[m]> in particular, chiptool don't use owned struct for peripheral, so i wonder if it's use another way to prevent to accidentally use the same peripheral at different place in the code ?

13:55 <FlixtheNewbie[m]> I'm updating the API of my library for embedded, so that it accepts static data. Unfortunately, I used to allowing writing operators for creating the data (it's for a keyboard, so think something like `Ctrl + Alt + Delete`.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/TZnEXhimXjLssbEDJEKaTfCH>)

13:58 <korken89[m]> <dirbaio[m]> "are you using the cc310, or..." <- I was playing with the AES CCM peripheral

14:00 <korken89[m]> Never tried the ECB as it only supports encryption

14:01 <korken89[m]> Hmm I should be able to make it work in transparent mode with the radio

14:01 <korken89[m]> It does say it should be fast enough for RF transfers

14:15 <yruama_lairba[m]> Félix the Newbie : is "keycode.keys()" a const method ?

14:34 <FlixtheNewbie[m]> <yruama_lairba[m]> "Félix the Newbie : is "keycode...." <- Hey, thanks for the answer. I did a bit of research, and to summarize, they removed the ability to use a const implementation of the std traits.

14:34 <FlixtheNewbie[m]> s/use/have/, s/of/for/

14:36 <FlixtheNewbie[m]> See: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=85b8dd447afb6e68706744b8171b3e2f

14:36 <waveguide[m]> <yruama_lairba[m]> "in particular, chiptool don't..." <- It’s left to the hal to setup owned objects

14:38 <yruama_lairba[m]> waveguide: so i need to check for example in a HAL using chiptools ?

14:41 <waveguide[m]> I believe the embassy code base would be a good starting point     

14:56 <yruama_lairba[m]> weird i have an error when trying to clen the repo

14:56 <yruama_lairba[m]> gnutls_handshake() failed

15:01 <thejpster[m]> <adamgreig[m]> "> <@thejpster:matrix.org> I do..." <- I don’t think so? I can’t remember what it was set to and now I turned it off GitHub doesn’t remember either. MQ doesn’t make sense for my main anyway though, because there’s only one release at a time, so it’s fine.

15:02 <adamgreig[m]> fair enough. when you turn MQ on, you choose whether it should rebase or merge commit, so probably it was just set wrong for you

16:14 <FlixtheNewbie[m]> Can I write the FLASH at runtime? For example, if I create a static MaybeUninit, it's stored in the flash, and during the initialization, I write the actual data.

16:31 <jannic[m]> With many MCUs, there is a way to write to flash at runtime, but there's no standard way to do so. However, a static MaybeUninit in flash is tricky to get right (if possible at all). You wouldn't write to the flash location by just writing to the variable, but through some MCU specific API. But the rust compiler doesn't know that this initializes the static variable. So from the rust compilers point of view, it's a variable that

16:31 <jannic[m]> never gets initialized. Which allows "optimizations" which are obviously wrong if the value is meant to be a different one after writing to flash.

16:50 <FreeKill[m]> jannic: In this case, the variable should be marked as volatile

16:50 <FreeKill[m]> In C, at least. I assume the same semantics are required in Rust

16:52 <jannic[m]> There are no volatile variables in Rust, only volatile accesses to variables. So you'd need to hide the static variable behind some facade to make sure nobody reads them directly, bypassing the volatile access. At which point, the simplicity of "just have a static variable" is lost.

16:57 <FlixtheNewbie[m]> Yeah... thanks for the answer, I guess I'll have to rewrite my API from scratch so that it's const-compatible. It's not cool how bad the const support in Rust is

16:59 <FlixtheNewbie[m]> I've read a few lines of Zig, and I have to say their const support is amazing.

17:00 <jannic[m]> That's what I came up with for the rp2040: https://github.com/jannic/rp2040-flash/blob/master/examples/flash_example.rs#L36-L45

17:00 <jannic[m]> Note that this doesn't use `volatile` as here the point isn't to guarantee the value is read again and again at every access, but only that the compiler generates code to read the variable at all (instead of assuming it to be constant and optimizing it away entirely).

17:01 <FlixtheNewbie[m]> Thanks, but I'll just bite the bullet and rewrite my lib

17:01 <FlixtheNewbie[m]> At least the public part

18:19 <BenPyeHeThey[m]> Félix the Newbie What are you trying to read/write from flash? You could possibly use a `static mut`, set the link section and use your linker script to ensure it lands in flash.

18:20 <BenPyeHeThey[m]> * `static mut` `MaybeUninit`, set

18:20 <BenPyeHeThey[m]> A global static mut is still unsafe to access, you would need to ensure that wherever you write to it get's it 'right'

18:21 <BenPyeHeThey[m]> * A global static mut is still unsafe to access, you would need to ensure that wherever you write to it get's it 'right' for your specific MCU too

18:33 <thejpster[m]> You can’t put a static mut in Flash. Well I guess you can but any write will cause a HardFault. You can only typically write to flash by talking to the flash controller peripheral and asking it to erase pages and write sectors (NAND Flash) or bytes (NOR Flash).

18:33 <thejpster[m]> where the processor cores can actually see them, and sending erase/write commands usually locks the chip up for a while so reads won’t work. Most flashing code copies itself to RAM and turns off flash read access temporarily. Then you have to worry about interrupts!

18:33 <thejpster[m]> On an RP2040 it’s worse because the flash controller is on the end of an SPI bus (well a QSPI bus) so you have to talk to the QSPI controller to get it to send ease/write commands to the flash chip. And whilst you’re doing that you can’t execute code from the flash chip. Executing code happens using the Execute In Place, or XIP, peripheral that knows how to read blocks from the flash chip and cache them in some special RAM

18:35 <thejpster[m]> Ok, scrolled back for context. I think they were talking about writing to flash during operation, and so a read from a static variable might change from one moment to another (because the world stopped and flash was re-written). If you used a static mut or an UnsafeCell maybe that would work? I’d be more comfortable with raw pointers though.

18:37 <BenPyeHeThey[m]> I didn't realise how flash writes worked on the RP2040 - in the few instances I've used the ability, you've had some unlock/erase sequence - but you then just wrote to memory as normal

18:39 <thejpster[m]> On both NOR and NAND fish you can only set a 1 bit to 0 on write. If you want to turn a 0 bit to a 1 bit you have to erase a whole page.

18:39 <thejpster[m]> EEPROM is byte writeable but any EEPROM is probably a NOR flash with a processor in front of it doing magic for you.

18:40 <BenPyeHeThey[m]> Right - which is another reason you'd need to use a linker script to give you a full page to use for whatever your NV storage is for

18:41 <BenPyeHeThey[m]> I guess you really need VolatileCell...

18:42 <thejpster[m]> Yeah I guess a linker script is a valid way to conjure up pointers.

18:42 <thejpster[m]> Anything with UnsafeCell in it. It’s the only way to have mutation through a shared reference.

18:42 <thejpster[m]> Once upon a time I wrote the U-Boot NAND driver for a TI Cortex-A chip, including hardware accelerated ECC.

18:42 <thejpster[m]> It would have been more fun in Rust.

18:44 <thejpster[m]> I think I’ve also written at least 3 key-value store systems from scratch. Hurray for not having a package manager built in!