00:38 <NiaLinaLunaStorm> I'm back at USB HID, made some progress but now am puzzled why it behaves the way it does. code is here https://codeberg.org/nayala/debugging-firmware... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/UXgQfVpEeSvIrRrEHCxNqyXs>)

00:39 <NiaLinaLunaStorm> since I'm setting here https://codeberg.org/nayala/debugging-firmware/src/branch/controller/firmware/src/main.rs#L141 the same value as the line above I'd expect both axis to report the very same but they don't

00:56 <NiaLinaLunaStorm> * I'm back at USB HID, made some progress but now am puzzled why it behaves the way it does. code is here [https://codeberg.org/nayala/debugging-firmware... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/FNpSeoCVMzMMmEKVHTmktPdY>)

00:57 <NiaLinaLunaStorm> * I'm back at USB HID, made some progress but now am puzzled why it behaves the way it does. code is here https://codeberg.org/nayala/debugging-firmware/src/commit/e8774ca4501d468fd6f60aef0a46caea39a4e4df/firmware/src... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/kgsnQSYSvZYcwhnlhyPACJPv>)

00:58 <NiaLinaLunaStorm> s/branch/commit/, s/controller/e8774ca4501d468fd6f60aef0a46caea39a4e4df/

00:59 <NiaLinaLunaStorm> when I make it fake 16 bit by multiplying by 16 I get it to work but that's not ideal cause 4095 * 16 is 65520 so below the max value of a 16 bit input

01:01 <JamesMunns[m]> Is the data just left aligned?

01:02 <JamesMunns[m]> Like 0xFFF0 max instead of 0x0FFF?

01:02 <JamesMunns[m]> You sometimes see that in sensors to hide the "bit depth"

01:03 <NiaLinaLunaStorm> but if that were the case, shouldn't I see this on both axis?

01:03 <NiaLinaLunaStorm> what throws me off here, is that the two axis are behaving differently

01:06 <JamesMunns[m]> Yeah, not sure!

01:19 <NiaLinaLunaStorm> I think I found a solution... return it as 16 bit but tell it it's the max value of a 12 bit thing

01:20 <NiaLinaLunaStorm> (which means I always need to mess with generated descriptors I use rn but at least a start)

01:20 <NiaLinaLunaStorm> ig thanks for being a rubber ducky!

01:23 <NiaLinaLunaStorm> one thing that still misbehaves tho is that it only reports its "manufacturer" and product name for a short moment and then it returns to be an unnamed device

02:15 <NiaLinaLunaStorm> <NiaLinaLunaStorm> "one thing that still misbehaves..." <- at least in lsusb and stuff like hidviz... in flightgear, it still showed up with its name now

02:16 <NiaLinaLunaStorm> anyway, late and really happy with the progress, nini

12:59 <AdamHott[m]> Is anybody at Embedded World that stopped by the Arm booth to checkout those dev kits that include the Ethos-U85 NPU?

12:59 <AdamHott[m]> Curious to know if anyone learned anything interest about that NPU

13:02 <JamesMunns[m]> huh, interesting. Basically a big array math accelerator?

13:03 <JamesMunns[m]> Looks similar in perf to Google's Coral TPU, but maybe more efficient (and glued to a Cortex-M?)

13:19 <birdistheword99[> This is probably a really stupid question, sorry, but I just want to confirm the difference between probe-rs run and probe-rs flash. I have my project set up to use probe-rs run as the runner in .cargo\config.toml, but does this only write to RAM? This doesn't actually flash the device like probe-rs flash? I also saw probe-rs embed exists, and seems to combine the two to some extent.

13:19 <birdistheword99[> * This is probably a really stupid question, sorry, but I just want to confirm the difference between probe-rs run and probe-rs flash. I have my project set up to use probe-rs run as the runner in .cargo\config.toml, but does this only write to RAM (not stored after power-cyle)? This doesn't actually flash the device like probe-rs flash? I also saw probe-rs embed exists, and seems to combine the two to some

13:19 <birdistheword99[> extent.

13:19 <dirbaio[m]> `probe-rs run` flashes (to flash, not to ram) and shows log output

13:19 <dirbaio[m]> `probe-rs run` flashes only

13:19 <dirbaio[m]> s/run/flash/

13:20 <AdamHott[m]> <JamesMunns[m]> "huh, interesting. Basically a..." <- Yeah seems like a great component for edge AI

13:20 <dirbaio[m]> cargo-embed is similar to probe-rs run but with a different featureset. they might get unified in the future

13:24 <birdistheword99[> dirbaio[m]: > <@dirbaio:matrix.org> `probe-rs run` flashes (to flash, not to ram) and shows log output

13:24 <birdistheword99[> Thanks, that clears things up. I was wondering how the hell it could not be in flash, but every-time I power my board off for a bit and come back to it later (just powered up with no debugger attached), it doesn't appear to be running the code. I guess its just the STM32H7 power/RCC issues as usual

13:24 <birdistheword99[> > `probe-rs flash` flashes only

13:24 <dirbaio[m]> oof, h7 power issues

13:27 <JamesMunns[m]> IIRC the history of flashing tools basically (2018 to present):... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/EhyyuTTTTuIiYobncGhiXrVI>)

13:33 <JamesMunns[m]> * IIRC the history of flashing tools basically (2018 to present):... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/bQNAnYbnhAlnOZbZEibXgOTh>)

15:28 <firefrommoonligh> `- cargo install cargo-binutils`

15:28 <firefrommoonligh> Good history. I will add one thing for building production firmware you can flash with third-party tools (DFU-utils, STM32cubeprogrammer etc):

15:28 <firefrommoonligh> `cargo objcopy --release -- -O binary target/firmware.bin`

15:28 <firefrommoonligh> s/`-/`/

15:30 <AdamHott[m]> I'm working on some schematics in KiCad and looking to reference other boards that have been built in KiCad to study for reference purposes. I've been looking at the rusty-probe and the esp-rust-board. Does anyone have any other good examples of open-sourced board that would be available on Github to review them in KiCad?

15:31 <firefrommoonligh> The answer will depend on what sort of thing you are building.

15:32 <firefrommoonligh> That said... I posted these UAV radio receivers as open hardware here; see the kicad_files subfolder: https://github.com/AnyLeaf/elrs-hardware

15:33 <firefrommoonligh> Note that the component placement on those boards make space compromises you wouldn't see on non-space-constrained designs.

15:34 <JamesMunns[m]> Throwing this out as an "enthusiastic hobbyist": https://github.com/OneVariable/ov-twin

15:35 <AdamHott[m]> It's an addressable RGB LED board that will have about 130 RGB LEDs x 60mA = 7.74 Amps. Needs ESD protection, voltage regulation, USB-C adapter, power on/off button, program start button, jumper boot switch

15:36 <JamesMunns[m]> that's a lot, tbh, and at ~40w you're going to have to deal with a lot of heat

15:36 <AdamHott[m]> yeah I know, it's a spicy meatball

15:36 <AdamHott[m]> :)

15:37 <ryan-summers[m]> Adam Hott: A project Id id a while ago and never finished, but the hardware was built and works: https://github.com/vertigo-designs/nano-bat

15:37 <AdamHott[m]> temperature sensor to prevent overheating

15:39 <AdamHott[m]> Thanks all!

15:40 <firefrommoonligh> I'm not sure if this is hitting that level of heat, but consider an aluminum PCB. Although they're generally for much higher current LEDs than that

15:40 <JamesMunns[m]> offhand:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ssKiALoMQAIeBrTVBHCzVWaP>)

15:41 <JamesMunns[m]> yeah, probably depends on the density. If you are fitting in like a light bulb shape, probably need alu. if you have a larger like laptop/monitor size, maybe not

15:42 <AdamHott[m]> This is for a prototype, which could become commercial

15:42 <firefrommoonligh> I agree with James on upping the voltage. You could do either, but you'll have more options for the DC-DC, and can get away with thinner traces if you do higher voltage.

15:42 <JamesMunns[m]> https://www.aliexpress.com/item/1005004463497983.html is something you can buy off the shelf

15:42 <JamesMunns[m]> (comes in a couple shapes and sizes!)

15:43 <JamesMunns[m]> you could do 12V3A from a USB-PD supply, drive the lights directly off that, then a simple buck or even LDO just for the MCU

15:44 <AdamHott[m]> Thanks for the pointers! James your board is coool!

15:44 <AdamHott[m]> You're doing a training on that one?

15:44 <AdamHott[m]> or workshop I mean

15:44 <JamesMunns[m]> AdamHott[m]: yep, the RustNL workshop will use that!

15:45 <JamesMunns[m]> JamesMunns[m]: Ah, seems 9V and 15V are more common for PD, might still need a buck :/

15:51 <AdamHott[m]> we'll see!

16:13 <dngrs[m]> 12V off USB-C should be fine, I've used https://a.aliexpress.com/_EGGXuJll

16:13 <dngrs[m]> In combination with https://a.aliexpress.com/_EHC0Nr11

16:14 <dngrs[m]> (The latter is kinda massive overkill for an MCU board though)

16:33 <AdamHott[m]> Thanks!

20:41 <mali[m]> I stumbled on this HN article today: [The simple beauty of XOR floating point compression (clemenswinter.com)](https://clemenswinter.com/2024/04/07/the-simple-beauty-of-xor-floating-point-compression/)

20:41 <mali[m]> The algorithm is pretty simple, and my time series sensor values would be compressed pretty good.

20:41 <mali[m]> And although it seems that fp64 was overkill, I wondered whether embedded has a use case here.

20:45 <mali[m]> It also seems that the code is in Rust, but std. https://github.com/cswinter/LocustDB/blob/e6044bf2af810af7a2932c3a51fbe301843f8d6a/locustdb-compression-utils/src/xor_float/single.rs