03:30 <morfertaw[m]> <haobogu[m]> "Did you try to prepend the..." <- I tried prepending the report id today, but that does not work either.

07:26 <badyjoke[m]> Hello ! Has anyone tried using https://github.com/lobaro/FreeRTOS-rust ? I get this error :

07:26 <badyjoke[m]> ``````

07:26 <badyjoke[m]> * Hello ! Has anyone tried using https://github.com/lobaro/FreeRTOS-rust ? I get this error :... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/mzBJTJDmGCefjdUMlFFotsXR>)

07:27 <badyjoke[m]> And I can't see a way of reducing the size

08:08 <JamesMunns[m]> That's telling you that your static RAM usage, (.bss and .uninit) don't fit into the RAM region. If you are building in release mode, and the linker script is correct (e.g. not undersized for your chip), there's not much to be done. I'm not sure how configurable freertos-rust is.

08:45 <Lumpio-> Then again just FreeRTOS should not take that much, make sure you're in release mode first I guess

09:45 <thejpster[m]> You could also look at https://github.com/ferrous-systems/freertos-experiments

09:45 <thejpster[m]> I think freertos uses only what you tell it to use.

09:56 <JamesMunns[m]> diondokter saw this in `cargo bloat` today and thought of you lol:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/FbARpWzEECnchCAQuayyKVJw>)

09:56 <diondokter[m]> Yep! That's the one

09:57 <diondokter[m]> Gonna fix that up soon hopefully

10:43 <morfertaw[m]> <morfertaw[m]> "I tried prepending the report id..." <- Curiously, I used a usb sniffer to see the hid descriptor. Without the report id it was able to return the hid descriptor but when I added the report id it was no longer able to show the hid descriptor.

10:44 <morfertaw[m]> morfertaw[m]: Here is the hid report descriptor with the id. `const KEYBOARD_ID: u8 = 0x01;... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/qAqQGxpKaaemVRaTeJkOctgK>)

10:44 <morfertaw[m]> * Here is the hid report descriptor with the id.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/qNeIhSZRGbYhvqCrjwXQNgJV>)

10:45 <morfertaw[m]> * Here is the hid report descriptor with the id.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/YagUrbclpWxzXUSjelzmQkTx>)

10:46 <morfertaw[m]> * Here is the hid report descriptor with the id.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/RxypiMbGaRDTkbBUwOHNmEFC>)

11:47 <alexmoon[m]> <morfertaw[m]> "Here is the hid report descripto..." <- > <@morfertaw:matrix.org> Here is the hid report descriptor with the id.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/saIDkMGdFlcRcsEdNnBUAsYd>)

13:29 <badyjoke[m]> The issue I had was comming from my FreeRTOSConfig.h. I took an already existing one without cheeking the minimal stack size and total head size. 🥲

13:29 <badyjoke[m]> s/head/heap/

13:56 <sirhcel[m]> Henk: Just saw your pr [discovery/#568](https://github.com/rust-embedded/discovery/issues/568) and to me it looks like the last sentence of the description should read _[...] The goal is for the book in this repo to only support Microbit:V2_. Is this right? I'd like to ask you here before making such noise in the gh discussion.

13:57 <sirhcel[m]> * Henk: Just saw your pr [discovery/#568](https://github.com/rust-embedded/discovery/issues/568) and to me it looks like the last sentence of the description should read _\[...\] The goal is for the book in this repo to only support Microbit:V2_. Is this right? I'd like to ask you here before making such nitpicking noise in the gh discussion.

13:57 <sirhcel[m]> * Henk: Just saw your pr [discovery/#568](https://github.com/rust-embedded/discovery/issues/568) and to me it looks like the last sentence of the description should read _\[...\] The goal is for the book in this repo to only support Microbit:V2_. Is this right? I'd like to ask you here before making such nitpicking noise in the gh issue.

14:06 <Henk[m]> <sirhcel[m]> "Henk: Just saw your pr [..." <- Oops, yeah that seems fairly vital. Thanks for the heads up

14:08 <sirhcel[m]> Henk[m]: The internet is right again. 😅 Thank you for the quick fix.

17:24 <cr1901> diondokter[m]: At a high-level, how does sequential-storage handle "old key written with new value"? Does erase/rewrite happen immediately, or does sequential-storage try another page first (to avoid an erase cycle)?

17:25 <dirbaio[m]> it doesn't modify it in-place, it writes a new copy of the key at the end. both to save on erases, and to ensure it's power-fail-safe.

17:26 <cr1901> How does sequential-storage know to use the new copy?

17:26 <dirbaio[m]> last one wins

17:26 <cr1901> ahh

17:27 <cr1901> Anyways, I just got confirmation that my menu UI survives saving cfg to EEPROM :D

17:28 <cr1901> I just don't want a nasty "EEPROM is full" surprise as I'm repeatedly testing writing configs

17:29 <cr1901> Would that be expected during normal operation (and thus I should include an "erase?" ui at the beginning), or should sequential-storage automatically try hard to avoid "EEPROM is full" if I'm repeatedly overwriting old keys w/ new values?

17:29 <dirbaio[m]> when it gets full it does some sort of "GC" I think

17:30 <dirbaio[m]> deleting "dead" versions of keys

17:30 <diondokter[m]> Kinda

17:31 <cr1901> Maybe I'll include an "erase?" UI just in case with cursor on "No" by default. My erase implementation is horrific anyway and I need to redo it.

17:31 <diondokter[m]> When it's full we're gonna erase the oldest page. But before that we see if the oldest page contains any key that isn't found in any of the newer pages. If it is the only one, it's migrated to the buffer page

17:32 <diondokter[m]> You can calculate whether all keys fit

17:32 <diondokter[m]> Only if there's literally no more space to store it after all key duplication is removed will it return that the storage is full

17:33 <cr1901> Okay cool, works for me

17:42 <diondokter[m]> Btw, do check out the readme. A lot of stuff like this is written there

20:11 <GuineaWheek[m]> i'm not super knowledgeable about how cargo works but i'm getting this error with defmt 0.3.7:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ASSZleYbeoDhLDSptdyoTVQO>)

20:16 <GuineaWheek[m]> downgrading doesn't seem to help either...

20:19 <mameluc[m]> https://github.com/rust-embedded/embedded-hal/blob/a0ccb6579669804e9be723912ed645a16362c8a6/embedded-hal/src/i2c.rs#L192

20:19 <mameluc[m]> https://github.com/rust-embedded/embedded-hal/blob/a0ccb6579669804e9be723912ed645a16362c8a6/embedded-hal/Cargo.toml#L23

20:20 <mameluc[m]> hmm thought it should have been defmt_03 but there is a crate:defmt_03 as defmt

20:21 <GuineaWheek[m]> it all seemed to compile fine before today..

20:21 <GuineaWheek[m]> in my cargo.toml i have embedded-hal = { version = "1.0.0", features = ["defmt-03"]}

20:21 <mameluc[m]> try cargo clean?

20:21 <GuineaWheek[m]> still nope

20:22 <GuineaWheek[m]> defmt pushed out a new point release today and i'm not sure what happened

20:24 <mameluc[m]> what rust toolchain version are you on?

20:25 <GuineaWheek[m]> how do i check this again

20:25 <mameluc[m]> idk actually. I just run rustup update when in doubt 😅

20:25 <mameluc[m]> or I have an rust-toolchain.toml file

20:26 <mameluc[m]> my thinking is that maybe something in the change doesn't play nice with some old nightly version or something making defmt fail.

20:27 <GuineaWheek[m]> still persists after rustup update

20:28 <diondokter[m]> Hmmm yeah, looks like defmt 3.7 bumped the msrv to at least a version of the compiler that includes the core::net module

20:28 <cr1901> diondokter[m]: Ack re: "read next time" :D

20:31 <diondokter[m]> GuineaWheek[m]: Can you see two different versions of defmt being used if you do `cargo tree -i defmt`?

20:32 <GuineaWheek[m]> everything is only using v0.3.7

20:32 <diondokter[m]> Ok good

20:32 <mameluc[m]> do you have a rust-toolchain.toml file?

20:33 <diondokter[m]> What's the output of cargo -V? (In the root of your project)

20:33 <mameluc[m]> rustup show actually shows what version is being used

20:33 <diondokter[m]> That works as well

20:33 <GuineaWheek[m]> cargo 1.80.0-nightly (4de0094ac 2024-05-09)

20:33 <mameluc[m]> ooh cargo -V is even nicer. TIL

20:34 <diondokter[m]> GuineaWheek[m]: That should do fine as well

20:37 <diondokter[m]> Ah yes, I can reproduce when I import embedded-hal with the defmt-03 features

20:37 <diondokter[m]> * Ah yes, I can reproduce when I import embedded-hal with the defmt-03 feature

20:37 <diondokter[m]> Not sure what's going on

20:38 <mameluc[m]> https://github.com/knurling-rs/defmt/issues/833

20:40 <diondokter[m]> I've got a feeling of what might be happening. This happens in embedded-hal where they renamed defmt to defmt-03. Perhaps that's now broken

20:43 <diondokter[m]> Yeah, with defmt 3.6 everything compiles fine

20:45 <diondokter[m]> Ok, with defmt at 0.3.7 it still compiles. Let's update the macros crate

20:45 <diondokter[m]> Yeah, now it breaks

20:45 <diondokter[m]> It is something that changed in the macros

21:05 <diondokter[m]> Same errors if you do cargo check --features defmt-03 on the embedded-hal crate directly

21:32 <diondokter[m]> https://github.com/knurling-rs/defmt/pull/835

21:39 <diondokter[m]> Urhengulas: If you see this, I think this is important to fix

21:40 <diondokter[m]> Guinea Wheek: I suggest pinning `defmt-macros` to the previous version

22:10 <KurtisDinelle[m]> Hey everyone, pretty new to Rust in general but I'm working on an embedded-hal driver for an I2C device. I want my driver to support both async and regular blocking I2C calls. The only difference is that the blocking version doesn't use .await after I2C calls or declare its functions async.

22:10 <KurtisDinelle[m]> Currently I use the duplicate crate to create two copies of the driver implementation (so I didn't have to manually maintain two very slightly different copies) as seen here: https://github.com/kurtjd/tsl2591-rs/blob/main/src/lib.rs#L161

22:10 <KurtisDinelle[m]> But I'm wondering if there is a better, "proper" way to handle this. Haven't been able to find any drivers that try to do this as an example, so not too sure. Any advice appreciated!

22:12 <diondokter[m]> KurtisDinelle[m]: > <@kurtjd:matrix.org> Hey everyone, pretty new to Rust in general but I'm working on an embedded-hal driver for an I2C device. I want my driver to support both async and regular blocking I2C calls. The only difference is that the blocking version doesn't use .await after I2C calls or declare... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/XVICAcxguftzbBBdPRCxTRjX>)

22:14 <diondokter[m]> In any case, I think everyone has a different opinion on supporting sync and async. There is no *proper* way.

22:14 <diondokter[m]> However, do keep in mind that async is not just blocking with some extra keywords. People can cancel futures and ideally everything should still be fine or it's documented somewhere what the possible effects of the cancellation are

22:15 <KurtisDinelle[m]> diondokter[m]: > <@diondokter:matrix.org> In any case, I think everyone has a different opinion on supporting sync and async. There is no *proper* way.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/uBKFTxmTVoyjamgImQbsKFxA>)