02:35 <ainedixon[m]> <adamhott[m]> "here's my template you can use..." <- Thanks, it helps

07:23 <JamesMunns[m]1> <ainedixon[m]> "Thanks, it helps" <- If there's something that was missing in the book, could you please open an issue, mentioning which part from Adam's repo helped you? I'd like to make sure we get this improved!

09:22 <adamhott[m]> <JamesMunns[m]1> "If there's something that was..." <- Bart M. helped me spruce this template up, he's aware of it. He wanted to include it in the book I believe.

09:55 <Henk[m]> I think opening an issue wouldnt hurt regardless

13:15 <MurrayToddWillia> <M9names[m]> "Murray Todd Williams: does..." <- > <@9names:matrix.org> Murray Todd Williams: does your project have a dependency on portable-atomic with the critical-section feature enabled?

13:15 <MurrayToddWillia> > That being missing would be my guess

13:15 <MurrayToddWillia> I don't know how to trace what is pulling portable-atomic in. I'm literally just starting with the base rp-pico 0.9.0 that comes with the rp2040-project-template. You can see my current configuration here: https://github.com/murraytodd/rp2040-blinky

13:17 <MurrayToddWillia> MurrayToddWillia: @9names: if I just add the embedded-hal-bus 0.2.0 to that `Cargo.toml`, the error appears.

13:30 <M9names[m]> You can check where dependencies come from using cargo tree

13:33 <M9names[m]> But it doesn't tell portable-atomic how to do its job, because there's multiple incompatible ways that could happen.

13:33 <M9names[m]> I'm not at a PC but I'm pretty sure embedded-hal-bus depends on portable-atomic to use atomic operations on targets that don't support them, like rp2040.

13:33 <M9names[m]> Which is why I suggested that if you do so, it might just fix your problem.

14:06 <MurrayToddWillia> Okay, so for my own understanding, let me play things back. This has to do with the fact that the rp2040 has two cores, so rather than assuming `portable-atomic` should use it's own critical-section based on single-core assumptions, we have to tell `portable-atomic` to expect an external implementation, which in fact has already been included by the `critical-section` crate that was already included by `rp2040-pac`.

14:06 <MurrayToddWillia> Ergo, adding `portable-atomic = { version = "1.6.0", features = ["critical-section"] }` to my own `Cargo.toml` is necessary so that it knows to include its own `compare_exchange` method. (I did add that to my `Cargo.toml`, and the issue appears to have gotten resolved.)

14:09 <MurrayToddWillia> * Okay, so for my own understanding, let me play things back. This has to do with the fact that the rp2040 has two cores, so rather than assuming `portable-atomic` should use it's own critical-section based on single-core assumptions, we have to tell `portable-atomic` to expect an external implementation, which in fact has already been included by the `critical-section` crate that was already included by `rp2040-pac`.

14:09 <MurrayToddWillia> Ergo, adding `portable-atomic = { version = "1.6.0", features = ["critical-section"] }` to my own `Cargo.toml` is necessary so that it knows to include its own `compare_exchange` method. (I did add that to my `Cargo.toml`, and the issue appears to have gotten resolved.)

14:09 <MurrayToddWillia> If that's all correct, would it make sense to either suggest the `rp2040-project-template` include that line by default or for either the `rp-pico` or `rp2040-hal` projects explicitly add that feature? I'd like to figure out if there's a good way to save the next beginner from this stumbling block.

14:42 <ViktorDemk[m]> Hello, does anyone here have some experience with lora-rs? I'm wondering how I can change the tx params like datarate, bandwidth and spreading factor. I'm running a stm32wle5