08:00 <JamesMunns[m]1> <takkaryx[m]> "started looking for a static..." <- btw, I'm interested if it NEEDS to be protobuf, or if you are using Rust on both sides. I'm working on `postcard-rpc` to address this and some other common "PC to MCU APIs", and USB is the best supported option today :D

08:33 <henrik_alser[m]> <JamesMunns[m]1> "btw, I'm interested if it..." <- I guess noone would choose protobuf out of free will right? 😬😅👀

08:36 <henrik_alser[m]> Yeah takkaryx if you have the option, definately go postcard

09:11 <Ralph[m]> <henrik_alser[m]> "I guess noone would choose..." <- why? not talking about embedded here (never used it in that environment), but for large scale distributed enterprise software it certainly makes sense as it's an efficient way to transport lots of information and do so in a versioned & backwards compatible manner (if you follow certain principles, anyway). combine it with something like apache kafka and you have a quite solid

09:11 <Ralph[m]> system, though it comes with some costs, of course.

09:23 <JamesMunns[m]1> I'm guessing it was mostly tongue in cheek: at least personally I don't have any problems with it, but it's not awesome on embedded, when you don't have a heap, and are likely perf sensitive.

09:29 <henrik_alser[m]> Yeah sorry for not providing context, it was tongue in cheek for the reasons James Munns pointed out :)

09:30 <henrik_alser[m]> * in cheek and for the

09:31 <henrik_alser[m]> I also use it a lot on server systems, i was just referring to constrained systems

09:32 <henrik_alser[m]> And in general it has given me a bit of headache but may very well be me that is stupid, not protobuf, i’m aware :)

09:32 <henrik_alser[m]> Ralph: ^^

13:52 <AlexandrosLiarok> <henrik_alser[m]> "I guess noone would choose..." <- I have used it to store forwards-compatible presets across firmware updates. It works nicely due to having great tooling for importing and exporting to the desktop, providing visualization and being able to allow users to build editors using the schema.

14:12 <henrik_alser[m]> <AlexandrosLiarok> "I have used it to store forwards..." <- I can change! (if i have to 😜)

20:08 <firefrommoonligh> <barafael[m]> "So I still have to use libm..." <- Yea. Try num_traits with libm. It will give you sqrt, abs, cos, sin etc; a lot of the methods on numbers you get in std but not no_std

20:09 <firefrommoonligh> I use it in most of my firmware

21:42 <NiaLinaLunaStorm> when I try to add a 3rd axis to my USB HID device, I run into a BufferOverflow UsbError: https://docs.rs/usb-device/0.3.2/usb_device/enum.UsbError.html

21:42 <NiaLinaLunaStorm> how do I find out which buffer this is?

21:42 <NiaLinaLunaStorm> code which works is here: https://git.nayala.duckdns.org/fly/A320-homecockpit/src/branch/main/Pedestal/firmware

21:43 <NiaLinaLunaStorm> from there I increased all the arrays to be size 3 instead of 2 and modified the descriptor:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/MbyCgbIHGChvgSnGgQNsblTV>)

22:00 <NiaLinaLunaStorm> chainging OutBytes8 and InBytes8 to the 64 variant seems to fix it... I would like to understasnd why tho (and what can be done once I get to that 64 bit limit

22:04 <NiaLinaLunaStorm> s/bit/byte/

23:01 <dngrs[m]> <NiaLinaLunaStorm> "chainging OutBytes8 and InBytes8..." <- maybe with the `control-buffer-256` feature of `usb-device`, not sure if it applies to your specific problem but I ran into some memory issues in the past that were fixed by that

23:29 <M9names[m]> I think the data for hid is in interrupt transfers? The max size it dictated by the speed.

23:29 <M9names[m]> https://www.beyondlogic.org/usbnutshell/usb4.shtml#Interrupt

23:29 <M9names[m]> * I think the data for hid is in interrupt transfers? The max size is dictated by the speed.

23:29 <M9names[m]> https://www.beyondlogic.org/usbnutshell/usb4.shtml#Interrupt