02:05 <rukai[m]> Anyone know of a USB mouse crate I could use to give mouse capabilities to a keyboard like embedded device that is currently using keyberon to act as a keyboard? I didn't see anything on Google, seems I might need to build my own?

02:09 <JamesMunns[m]> I thought the usb-device crate had HID definitions enough to do mouse stuff

02:09 <JamesMunns[m]> I've done it a long time ago

02:10 <JamesMunns[m]> <rukai[m]> "Anyone know of a USB mouse crate..." <- Not sure how up to date it is, but: https://docs.rs/usbd-hid/latest/usbd_hid/

02:10 <JamesMunns[m]> https://docs.rs/usbd-hid/latest/usbd_hid/descriptor/struct.MouseReport.html

02:22 <rukai[m]> Ooooh, thanks, I'll take a look

02:29 <JamesMunns[m]> elpiel re: https://twitter.com/elpiel_/status/1725826407509496232

02:29 <JamesMunns[m]> In general, debug builds in Rust are (in my experience) 10x to 100x slower than release builds. One very common source of this slowness is that debug build do no inlining, so things like doing iteration, which could be optimized to an instruction or two with inlining, are actually like 15 function calls in debug (think deref, then indexing, then mapping...)

02:29 <JamesMunns[m]> Yeah, debug symbols like line numbers and such exclusively live in the ELF, of which only some sections are actually loaded into flash when you program your device.

02:30 <JamesMunns[m]> This wreaks havoc with any predictable performance, especially with timing sensitive comms, like USB, or similar

02:31 <JamesMunns[m]> I think the size penalties for debug vs release aren't QUITE as bad as the perf ones, but 2-10x size wouldn't surprise me

02:53 <M9names[m]> <rukai[m]> "Anyone know of a USB mouse crate..." <- https://github.com/dlkj/usbd-human-interface-device is also really good

03:17 <TommyG[m]> what are some good ways to guard against breaking timing sensitive code?

06:03 <elpiel[m]> <JamesMunns[m]> "elpiel re: https://twitter.com/..."; <- Thank you James for your explanation.

06:03 <elpiel[m]> So at the end there are some debug symbols that are flashed, this is quite interesting.

06:03 <elpiel[m]> I will definitely share this knowledge to other people as well 😋

07:35 <henrik_alser[m]> Tommy G: Run it in interrupt context at a higher priority level than the rest of the code. Or if you’re using a multicore device (like rp2040) you can run it on a separate core

09:13 <Ralph[m]1> <dbrgn> "Hi folks! In https://github.com..." <- i didn't see any answers to this. first of all: thanks a lot for your work, Danilo!... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/wkOrroZpaTHBjTsyReLPjZFO>)

10:44 <JamesMunns[m]> <elpiel[m]> "Thank you James for your..." <- > <@elpiel:matrix.org> Thank you James for your explanation.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/giTZOtNPBXIlTmzuVPASHkfj>)

10:46 <JamesMunns[m]> Only some sections of the ELF are flashed, of which the debug sections are not included. Only the sections (like .text, etc.) needed at runtime are flashed. Sorry for not being so clear there

11:04 <thejpster[m]> https://github.com/rust-lang/unsafe-code-guidelines/issues/411 is still bubbling along.

11:04 <thejpster[m]> Is it possible to rework PACs so they present the same API but without using VolatileCell?

11:25 <dirbaio[m]> yes, chiptool uses raw pointers only, no VolatileCell

11:25 <dirbaio[m]> and presents an almost-identical API to svd2rust

11:28 <dirbaio[m]> (it could be made more almost-identical, most differences are orthogonal)

11:28 <dirbaio[m]> the only required differences are

11:29 <dirbaio[m]> - user code holds `RegisterBlock` instead of `&RegisterBlock` (`RegisterBlock` *contains* a raw pointer, so same size)

11:29 <dirbaio[m]> - reg access is a method: `regs.foo()` instead of `regs.foo`

16:05 <thejpster[m]> That’s a ton of breakage for HALs though

16:06 <firefrommoonligh> I would be happy doing a breaking change if it made things more consistent between MCUs

16:06 <thejpster[m]> I guess the issue is it’s the reference that holds the address to the peripheral and the simple fact you have a reference means the compiler can read from it

16:06 <firefrommoonligh> For STM32 so much code goes into smoothing over DVD/PAC convention differences

16:07 <firefrommoonligh> s/DVD/SVD/

16:07 <thejpster[m]> So you can’t fix it whilst having a reference to a thing that doesn’t exist

16:08 <thejpster[m]> You could have a reference to a static … but that’s chewing up RAM.

16:08 <thejpster[m]> Hmmm. Can you have a reference to a static ZST? Does that use RAM?

16:08 <JamesMunns[m]> yes, iirc.

16:08 <thejpster[m]> Yes to the first or yes to the second?

16:09 <JamesMunns[m]> can you, yes, does it use ram, yes

16:10 <thejpster[m]> “We blew 64 bytes of RAM fixing a theoretical unsoundness” isn’t great….

16:10 <JamesMunns[m]> https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d2f28bdc7670bfb2cf497ccbfe0af25a

16:11 <thejpster[m]> Right, the reference is still a word on the stack

16:11 <thejpster[m]> But that says BOB uses zero bytes

16:11 <thejpster[m]> I wonder what BOB’s address is

16:11 <thejpster[m]> And if you have SAM does it have the same address?

16:12 <JamesMunns[m]> thejpster[m]: it's a dangling pointer

16:13 <JamesMunns[m]> ah, maybe not. something else uses dangling pointers in the zst case

16:14 <JamesMunns[m]> https://doc.rust-lang.org/nomicon/vec/vec-zsts.html#allocating-zero-sized-types

16:15 <thejpster[m]> https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=10826dd407b4051108732b08a9f11c51

16:16 <thejpster[m]> They have the same address. At least on whatever the playground runs.

16:16 <JamesMunns[m]> Yeah, makes sense, C++ requires that ZST addrs are unique (I think?), but Rust doesn't

16:17 <thejpster[m]> So you could have a type for each peripheral with fields that are all zero sized and give people references to it.

16:17 <thejpster[m]> and read() and modify() can conjure up pointers on demand

16:21 <dirbaio[m]> Many hals manipulate the singletons only, not the &RegisterBlock

16:22 <dirbaio[m]> So it wouldn't be that breaking 

16:22 <dirbaio[m]> What's more breaking is making everything a method 

16:22 <dirbaio[m]> But the fix is ver mechanical, just add () everywhere 

16:22 <dirbaio[m]> s/ver/very/

16:23 <dirbaio[m]> I wouldn't do "reference to zst" hacks to keep kabwards compat, the generated code is already cursed enough 

16:24 <dirbaio[m]> And it's not that useful because there's no way around the other breaking change afaict anyway (the "add ()" thing) 

16:34 <JamesMunns[m]> <thejpster[m]> "So you could have a type for..." <- I still this this is breaking, as I've seen (and probably written) stuff that looks like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/kTpqMlwqksRkDHbYbCQmVywc>)

16:35 <thejpster[m]> wtf

16:35 <JamesMunns[m]> and agreeing with dirbaio, that only works if you can reference a subfield, which then brings you back to the point that if you can get the addr of a register the compiler as a reference the compiler can do a spurious load

16:35 <JamesMunns[m]> thejpster[m]: not sure what you're wtf-ing about, this is specified behavior in the PAC model, afaik.

16:36 <thejpster[m]> About the field ref thing. My mind is blown.

16:37 <JamesMunns[m]> setting up DMA from a peripheral means getting the address of the register that does a read from that peripheral. Because we have a reference to a struct of the peripheral's fields, the address of the subfield is the correct address to use there.

16:40 <JamesMunns[m]> technically I guess the right way to do that would be something like dma2.setup_src(addr_of!(uart.in_reg), len), since that never takes a reference, but I don't think I've ever seen anyone actually write that :p

16:42 <JamesMunns[m]> whereas in chiptool it'd be dma2.setup_src(uart.in_reg(), len) or maybe .in_reg().addr(), can't remember if the accessor helpers degrade into a ptr

16:43 <JamesMunns[m]> ah .as_ptr()

17:01 <JamesMunns[m]> my $0.02, I think it'd make sense to start tackling the "what's next for PACs" starting next year, after the ehal 1.0 ships

17:17 <firefrommoonligh> I don't think PAC and EH are related or co-dependent

19:04 <diondokter[m]> What does esp do? Does it use svd2rust or chiptool or some custom thing?

19:04 <diondokter[m]> <JamesMunns[m]> "my $0.02, I think it'd make..." <- Not sure what I can and cannot say, but Infineon has opinions on this too.

19:07 <JamesMunns[m]> svd2rust, it seems: https://github.com/esp-rs/esp-pacs/blob/main/esp32c3/src/lib.rs#L1

19:08 <adamgreig[m]> infineon had some public discussion about these things a while ago iirc

19:10 <jessebraham[m]> Sorry just kind of jumping into this conversation and haven't read back. I have no strong opinions on `svd2rust` or `chiptool`. I chose `svd2rust` for the ESP stuff initially because that's what I was familiar with.

19:10 <jessebraham[m]> I'm not against switching, I just don't really understand the advantages of doing so (my fault) and it's a lot of work 😀

19:11 <JamesMunns[m]> Wasn't there a third thing too? svd2rust, chiptool, and ???

19:11 <jessebraham[m]> I recall some `ral` stuff, maybe that was STM-specific? Not sure

19:12 <JamesMunns[m]> yeah, I thought there was a third codegen tool, maybe it was just for RAL stuff tho

19:12 <adamgreig[m]> there's raltool

19:12 <adamgreig[m]> which is a fork of chiptool

19:12 <adamgreig[m]> and there's stm32ral, which is a python script specifically for stm32; raltool I believe takes some of the operating concepts from that python script and applied them to a chiptool fork

19:13 <burrbull[m]> I think svd2rust could support both vcell and direct register access based ways using option. Should be not hard to implement

19:15 <JamesMunns[m]> if anyone wants another $0.02 of my thoughts, before we start discussing this **next year**, it would be astoundingly helpful to have a written doc/blog post/issue comment/whatever that discusses:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/lpbNVwBfObzUuPXmCKudVgdx>)

19:15 <JamesMunns[m]> I think a lot of people are vaguely familiar with these tools and how they work, and even for experts, there are oversights on important details

19:16 <burrbull[m]> I'd do it by 2 steps. On first step change API making it closer to chiptool by https://github.com/rust-embedded/svd2rust/pull/692

19:16 <JamesMunns[m]> so much so that I think trying to discuss or evaluate options is going to be a bikeshed deathpit if we don't have a reasonable overview, and add to it as we discuss+compare+contrast, and that's even before suggesting new features for either.

19:18 <JamesMunns[m]> off topic, but I finally put up this PR :D

19:18 <JamesMunns[m]> https://github.com/rust-embedded/cortex-m/pull/496

19:23 <JamesMunns[m]> Probably a fun topic too: "how can we make it easier for chip designers to emit information we can use for codegen". This might be infineon, but also might be smaller (thinking risc-v) designers, all the way to hobbyists with amaranth, etc.

19:25 <JamesMunns[m]> but if OSS or proprietary VLSI tools spit out some kind of consistent metadata, making it painless to turn that into a pac/ral/whatever could be a very very neat way to hopefully help them bypass manual data entry errors, or at least make Rust support an easier ask.

19:26 <adamgreig[m]> I'd settle for them emitting information, we can work out the format :P

19:26 <adamgreig[m]> ideally not as C header files, perhaps

19:27 <adamgreig[m]> in principle SVD and the cmsis pack files cover this for a lot of arm devices, and a lot of non-arm devices too since it's an established format

19:27 <JamesMunns[m]> Sure, but if we write docs, and some intern there goes "hey I found this and we can just wire it up" sometimes that short-circuits change faster than "hey please give us your metadata" :p

19:27 <adamgreig[m]> but I guess the point is about the metadata not covered by svd, like pin assignments

19:27 <adamgreig[m]> (and of course the SVDs are atrocious, but I don't know that a change in format is likely to improve data quality)

19:27 <adamgreig[m]> s/the/some/

19:28 <adamgreig[m]> sadly I don't think there's any universal wiring up to what is presumably ultimately an excel spreadsheet

19:28 <JamesMunns[m]> I think the espressif folks ended up hand writing/scripting to make their SVDs?

19:28 <adamgreig[m]> I would love to be wrong if there is secretly one standard metadata format that everyone uses internally though :P

19:28 <jessebraham[m]> Lots of scripting haha

19:28 <jessebraham[m]> It's mostly automated now, but there's a fair bit of manual work to create a new one

19:29 <JamesMunns[m]> adamgreig[m]: I'd bet money on this too, but that blows my damn mind lol

19:29 <jessebraham[m]> We have our own internal register description format that I then massage into SVDs

19:30 <jessebraham[m]> I will also mention that I've found some deficinecies with SVDs in general, however I've been able to work around them

19:30 <jessebraham[m]> I'm not really aware of a better solution at this point so thought

19:30 <jessebraham[m]> s/thought/though/

19:30 <adamgreig[m]> ST publish basically all the data sources that STM32CubeMX uses to do its thing, so while it would be nice if the SVDs were somehow more consistent/better, most of the rest is present in their various XMLs, which is what embassy uses for instance

19:30 <jessebraham[m]> s/so thought/though/

19:31 <JamesMunns[m]> I think(?) chiptool imports from SVDs, into the yaml format, then does codegen on that? I know adams been poking around here lately

19:31 <adamgreig[m]> yea, SVD is kinda weird

19:31 <adamgreig[m]> it's also very poorly specified

19:31 <adamgreig[m]> like, there's a xml schema for it, which we put a load of effort into complying with, then some arm folk said oh btw these svds aren't valid at all, the schema isn't right, this requirement isn't actually documented anywhere, but it's what our svdconv software does so it's a requirement

19:32 <JamesMunns[m]> I wonder at what point we just publish a SQL schema, and start smooshing all the definitions into an sqlite database you can download at codegen time :p

19:32 <adamgreig[m]> like, "oh, you can't reference something being derived from something later in the file, only earlier in the file, even though all your tooling supports that, because our tool doesn't support that" sort of thing (plus things that genuinely could be in the schema but aren't)

19:32 <adamgreig[m]> and it's fair enough, there are good reasons for this, but it's a shame it's not more documented

19:33 <adamgreig[m]> the svds are at an annoying middle ground too where they can't generalise over families of chips, so if your company only sells 5 part numbers it's nbd, but if you're ST with like 1300, it gets annoying quickly

19:57 <JamesMunns[m]> I mean, if we look through the structure types between svd2rust and chiptool, I bet we have a pretty functional register definition schema :p