00:08 <RockBoynton[m]> <dirbaio[m]> "Can't make it into a crate" <- how does this work then? https://github.com/t-moe/defmt-or-log

00:38 <dirbaio[m]> <RockBoynton[m]> "how does this work then? https:/..." <- It doesn't

00:38 <dirbaio[m]> If you add just that crate as a dep, it breaks

00:39 <dirbaio[m]> You need to add defmt as well, and conditionally enable it

01:17 <RockBoynton[m]> <dirbaio[m]> "You need to add defmt as well..." <- well yeah, why is that worse than copy-pasting the fmt.rs file?

04:21 <cheap0[m]> I followed the tutorial and used the tool, but it still prompts the following

04:26 <M9names[m]> that image shows you setting the driver for the CDC interface. that's not the debug interface.

04:27 <M9names[m]> if it's a proper j-link, use the jlink tools to configure it instead:

04:27 <M9names[m]> https://kb.segger.com/J-Link_WinUSB_driver_selection

04:36 <cheap0[m]> <M9names[m]> "if it's a proper j-link, use the..." <- thank you,but It seems that this option cannot be toggled

04:39 <M9names[m]> weird. guess you will just have to work out zadig then, no fun.

11:46 <dirbaio[m]> <RockBoynton[m]> "well yeah, why is that worse..." <- Crate A and B depend on log-or-defmt. Both have `[features] defmt = ["dep:defmt", "defmt-or-log/defmt"]`. If you enable defmt on crate A, it breaks crate B because it causes defmt-or-log to start using defmt when crate B doesn't "expect" it because *its* defmt feature is not enabled. This problem doesn't happen if you copypaste fmt.rs.

13:00 <t-moe[m]> yeah, defmt-or-log shouldn't exist in the first place. But it made my life easier in practice, because of the FormatOrDebug trait...

13:00 <t-moe[m]> Thanks for reminding me, to push this forward again... https://github.com/knurling-rs/defmt/issues/730

13:00 <t-moe[m]> Anyways, I hope we'll get a better solution soon, when defmt can forward to the log backend internally.

13:28 <t-moe[m]> * yeah, defmt-or-log shouldn't be used in public crates. I've created it mainly to avoid copy/pasting fmt.rs and to have a location for the FormatOrDebug trait, for the local crates of my app.

13:28 <t-moe[m]> Anyways, I hope we'll get a better solution soon, when defmt can forward to the log backend internally.

13:28 <t-moe[m]> Thanks for reminding me, to push this forward again... https://github.com/knurling-rs/defmt/issues/730

13:30 <t-moe[m]> * yeah, defmt-or-log shouldn't be used in public crates. I've created it mainly to avoid copy/pasting fmt.rs and to have a location for the FormatOrDebug trait, for the local crates of my app. I enable log/defmt at the root (bin) crate and on all dependencies...

13:30 <t-moe[m]> Anyways, I hope we'll get a better solution soon, when defmt can forward to the log backend internally.

13:30 <t-moe[m]> Thanks for reminding me, to push this forward again... https://github.com/knurling-rs/defmt/issues/730

13:49 <t-moe[m]> * yeah, defmt-or-log shouldn't be used in public crates. I've created it mainly to avoid copy/pasting fmt.rs and to have a container for the FormatOrDebug trait, for the local crates of my app. I enable log/defmt at the root (bin) crate and on all dependencies...

13:49 <t-moe[m]> Anyways, I hope we'll get a better solution soon, when defmt can forward to the log backend internally.

13:49 <t-moe[m]> Thanks for reminding me, to push this forward again... https://github.com/knurling-rs/defmt/issues/730

17:37 <whitequark[cis]> non-additive features are evil

18:38 <thejpster[m]> Yes, but. Sometimes necessary.

18:40 <thejpster[m]> Like one HAL supporting multiple chips.

18:40 <thejpster[m]> Ideally cargo would understand this as a native concept (I don’t know, “build flags” or something) and give better errors, or just let you build a crate twice.

18:48 <realroot[m]1> how store things in flash with watchful?

18:49 <realroot[m]1> * with watchful? https://github.com/lulf/watchful

19:26 <igiona[m]> You can have a look at sequential_storage and use the Flash object use nrf_softdevice::Flash

19:27 <igiona[m]> static NRF_FLASH: StaticCell<Flash> = StaticCell::new();

19:27 <igiona[m]> let f = NRF_FLASH.init(Flash::take(sd));

19:30 <igiona[m]> ... This only if watchful is using softdevice ... detail I fail to remember on the top of my head

19:31 <igiona[m]> https://github.com/lulf/watchful/blob/main/pinetime-flash%2Fsrc%2Fflash.rs

19:31 <igiona[m]> I guess it's for the external flash (my hint was intended for the internal Flash)

20:05 <realroot[m]1> NOTE: If you've used watchful before 0.2.6, it now has switched from using `embassy-boot` to `mcuboot` as provided by default on InfiniTime. To achieve that, the [nrf-softdevice](https://github.com/embassy-rs/nrf-softdevice/) has been replaced with [trouble](https://github.com/embassy-rs/trouble).

20:07 <realroot[m]1> trouble is for BLE so never mind?

20:43 <igiona[m]> It looks like that even with trouble, the code is relying on some SD features to get access to the flash: https://github.com/lulf/watchful/blob/3e8543c47f4ff9323841a55b1b593c476a6cccbd/firmware/src/main.rs#L61C1-L61C43

20:43 <igiona[m]> Likely these features do not rely on the SD-stack and that's why it works... worth a try ;)

20:54 <realroot[m]1> do i check mpsl from use nrf_sdc::{self as sdc, mpsl}; then?

20:57 <igiona[m]> https://github.com/lulf/watchful/blob/3e8543c47f4ff9323841a55b1b593c476a6cccbd/firmware/src/main.rs#L192-L198

20:57 <igiona[m]> Here is were the internal flash is created, you can r/w on it with that object I guess.... I'm sorry though, I don't have the means to test anything... I guess you're on your own ;)

20:59 <realroot[m]1> thanks