08:57 <corecode[m]> is there a way to set a cargo config for examples only? i'd like to set the target to embedded for examples, but leave dev target at host for unit testing

10:13 <tr09[m]> <whitequark[cis]> "that will show all of the TCP..." <- It’s quite embarrassing but I was not launching the LF clock in init, so timestamp value was always 0.

10:13 <tr09[m]> Working as expected now.

13:17 <BenoitLIETAER[m]> Hello, having a rustup toolchain version issue again

13:18 <BenoitLIETAER[m]> cargo-embed requires 1.65.0 but for some reasons, it looks the thumbv7em-none-eabihfis stuck on 1.63.0 ?

13:18 <BenoitLIETAER[m]> not sure how to override and if/how I should use nightly here ?

13:18 <BenoitLIETAER[m]> (this time I don't mix OS packages with a clean rustup install only, I swear 😅)

13:19 <BenoitLIETAER[m]> For context: https://github.com/atsams-rs/atsamx7x-rust/tree/development/boards/atsamv71_xult

13:53 <marmrt[m]> <BenoitLIETAER[m]> "cargo-embed requires 1.65.0..." <- It is the `Cargo.toml` file of the pac

13:53 <marmrt[m]> https://github.com/atsams-rs/atsamx7x-rust/blob/development/pac/atsamv71q21b/Cargo.toml

13:53 <Noah[m]> <BenoitLIETAER[m]> "cargo-embed requires 1.65.0..." <- hmm should work just fine on the newest release :)

13:56 <BenoitLIETAER[m]> marmrt[m]: AH ! Is that safe to increment this forced version ? 🤔

13:56 <BenoitLIETAER[m]> Noah[m]: newest release of `rustup` or the eabihf toolchain or the git repo ? :)

13:57 <marmrt[m]> It should be fine. I have no idea why the compiler version would be locked for the PACs

13:58 <Noah[m]> BenoitLIETAER[m]: the eabihf toolchain should be available on the 1.72 rustc releas

13:58 <Noah[m]> s/releas/release/

13:58 <Noah[m]> BenoitLIETAER[m]: yep totally safe I think :)

13:59 <Noah[m]> marmrt[m]: yeah, sounds odd to me. maybe someone did not know better?

13:59 <Noah[m]> I have never seen compiler lock before other than nightly requirement

14:01 <marmrt[m]> I think those Cargo.toml files are all auto generated, so it feels like a detail that just got overlooked rather than an active choice

14:20 <jessebraham[m]> The `rust-toolchain` field is the MSRV, it's not locking to a particular compiler version

14:20 <jessebraham[m]> s/toolchain/version/

14:20 <jessebraham[m]> https://doc.rust-lang.org/cargo/reference/manifest.html#the-rust-version-field

14:22 <jessebraham[m]> Unless I've completely misunderstood this conversation and you're talking about something else haha

14:26 <BenoitLIETAER[m]> Actually, just pulling the generic eabihf toolchain triggers the 1.63.0 :/

14:26 <BenoitLIETAER[m]> Why ?

14:26 <BenoitLIETAER[m]> `$ rustup target add thumbv7em-none-eabihf`

14:29 <marmrt[m]> is it rust-toolchain.toml in the root directory?

14:33 <eZioPan[m]> wow, they got update the rust version

14:33 <eZioPan[m]> * they got to update the

14:41 <eZioPan[m]> hi, is there some way to access a register with u8 size raw pointer?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/KGcniRXVXnVholrIEqdcKtNk>)

14:43 <eZioPan[m]> I guess I need to avoid write to lowest 8 bits of CCR reigster, before I ready to start a transfer.

14:45 <eZioPan[m]> * hi, is there some way to access a register with u8 size raw pointer?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/NZUIQLnqyUkzUClMzTqrpTGQ>)

14:47 <adamgreig[m]> are you sure that register supports small writes? maybe you need to use modify() instead of write() to keep INSTRUCTION at the same value

14:48 <adamgreig[m]> you probably want more like unsafe { (qspi.ccr.as_ptr() as *mut u8).offset(1).write_volatile(1) };, I think you're currently writing a whole word away from what you want, but you may well not be allowed to do a single byte write, that's quite rare for mmio registers

14:52 <eZioPan[m]> uhm, I try the code you provide, but it still jump to HardFault

14:53 <eZioPan[m]> but the RM seems ask user not to write to INSTRUCTION if they don't want to trigger a transfer

14:54 <eZioPan[m]> I use .modify() originally, but it also trigger a transfer

14:55 <eZioPan[m]> or, the RM tells user should always set QUADSPI_CCR all in once?

14:57 <eZioPan[m]> can confirm write all in once do well

17:19 <meptl[m]> <meptl[m]> "I'm having issues creating a USB..." <- This was because I misconfigured the clock: I had 84.kHz() instead of 84.MHz() for sysclk.

17:45 <burrbull[m]> <eZioPan[m]> "hi, is there some way to..." <- > <@ezio_pan:matrix.org> hi, is there some way to access a register with u8 size raw pointer?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/dtRGhqCdLcVjEEutnNIUJUNQ>)

18:37 <thejpster[m]> There’s a discussion about pushing unmaintained targets down to Tier 3. This would mean no more support in rustup for fetching prebuilt libcore. This was prompted by codegen bugs in sparc64 Linux.

18:37 <thejpster[m]> https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Demote.20target.20.60sparc64-unknown-linux-gnu.60.20Tier.202.20-.3E.203

18:37 <thejpster[m]> If you want to maintain a Tier 2 target and keep it there, please do reach out on zulip.

18:39 <thejpster[m]> I note that all of the Cortex-M targets are currently unmaintained.

19:22 <adamgreig[m]> Perhaps the wg cortex-m team should be the maintainer

19:45 <eZioPan[m]> <burrbull[m]> "> <@ezio_pan:matrix.org> hi..." <- I’ve read the RM again, and it seems not possible to write CCR in u8 size…

19:54 <corecode[m]> does anybody here use jlinkgdbserver and itm logging? i just don't see any output (using itm-logger.rs)

21:12 <Noah[m]> Maybe I should do another survey what is lacking that people still use segger stuff ^^

21:46 <Jonas[m]1> I see that there is a Rust HAL for NRF 52840 in the nrf-rs repo. Anyone here that has some experience working with this HAL? I have not used any NRF board yet, only RP Pico 2040. NRF 52840 has interesting radio features, but as what I can see only a part of it is in the HAL yet, not so much of the Bluetooth? as of what I can see. Does the hardware have good documentation of the Bluetooth part, so that it is possible to use with Rust

21:46 <Jonas[m]1> or are there any hidden/difficult part that requires C libraries or BLOBs?

21:47 <adinack[m]> check out embassy:

21:47 <adinack[m]> https://github.com/embassy-rs/embassy

21:47 <adinack[m]> they have their own HAL and BLE support via nrf-softdevice

21:48 <IlPalazzo-ojiisa> Could anyone offer any quick help about how to power down an Arduino Nano using Rust?

21:54 <ilpalazzo-ojiis4> (Just did it using unsafe, but I'd prefer something more readable if anyone has anything)